• Review architecture of testing support in extension
• If we have major changes, then review overall architecture of the extension.

• Can be simplified by making the structure flat
• Each item will have a unique identifier (id)
• Proposed structure
  • Discovery - use what we have today
  • Test results (will be streamed back - events/response style)

// Add the following to each test
// This information will not be available on the file, suite level, etc..
result: {
	status: <enum status>,
	error: {line, reason, stack, ....}
	time: milliseconds
},

Adapter = Event<test, result> Model = Event<test, result>

ViewModel handle event - Model

Tree

• Use of python code instead of scraping stdout.
  • Python code to build, parse CLI args.
• Support streaming output (via stdout, socket, etc) through an abstraction.
  • With support to send data and logging into the same stream
  • I.e. message based protocol

• Improved testability

title: Testing Architecture


VS Code (TreeView) <-  VSC Integration (Provider/TreeView): Interaction


VSC Integration (Provider/TreeView) <-- Model (Bridge): _Events_
VSC Integration (Provider/TreeView) --> Model (Bridge): Request information

Model (Bridge) -> Python Code: Send Request
Python Code --> Model (Bridge): Stream Events
Python Code -> Model (Bridge): Send Response

• This is the VS Code treeview (UI).
• We interact with this via the Provider and the TreeView classes

• This the code that interacts with VSC
• The View Model layer

• This is the a layer that is the bridge between the VSC integration and the Python test classes.
• General design of this layer is:
  • This class will fire events for other classes that can listen to (e.g. tests discovered, tests passed, individual tests passed, etc...)
  • This layer is responsible for communicating with the Python code
  • Classes such as discovering tests can be found here (existing code that calls into Python and parses the data...)