Skip to content

Testing Architecture Review

Don Jayamanne edited this page Apr 4, 2019 · 6 revisions

Goals

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

Data Models

  • 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

Adapter for discovery, running & debugging

  • 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

General notes

  • Improved testability

Diagram

diagram

Diagram created on https://swimlanes.io

Click for details to create/edit

Instructions for editing diagram:

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

Details

VS Code (TreeView)

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

VSC Integration (Provider/TreeView)

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

Model (Bridge)

  • 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...)
Clone this wiki locally