-
Notifications
You must be signed in to change notification settings - Fork 278
Unit Tests
Writing unit tests is pretty straightforward but there are some things to consider.
The unit test for a particular class/file should have the same name as the class under test but end with unit.test.ts
instead. This makes it get picked up automatically when our tests run.
They generally follow a pattern like so:
suite(`My new unit test', () => {
let foo: IFoo;
setup(() => {
// setup mocks
foo = mock(FooClass); // Using ts-mockito to mock
when(foo.bar).thenReturn(true);
});
test(`Test baz`, async () => {
const baz = new Baz(foo);
assert.ok(baz.bar, `Bar is not correct');
});
});
Mostly we use ts-mockito to generate mock objects and sinon to stub out method calls.
In unit tests we try to follow the pattern of testing the public output of a particular class or function. Embedding internal details of a function class into a unit test ends up meaning the test is a copy of the function itself and makes it hard to maintain.
When a unit test fails (or you're just starting to write one), you can debug the test.
From the debug drop down in VS code, pick this launch.json entry:
Then click on the gear icon and edit the --grep
parameter to match your test.
You should be able to set a breakpoint directly in the test code.
- Contribution
- Source Code Organization
- Coding Standards
- Profiling
- Coding Guidelines
- Component Governance
- Writing tests
- Kernels
- Intellisense
- Debugging
- IPyWidgets
- Extensibility
- Module Dependencies
- Errors thrown
- Jupyter API
- Variable fetching
- Import / Export
- React Webviews: Variable Viewer, Data Viewer, and Plot Viewer
- FAQ
- Kernel Crashes
- Jupyter issues in the Python Interactive Window or Notebook Editor
- Finding the code that is causing high CPU load in production
- How to install extensions from VSIX when using Remote VS Code
- How to connect to a jupyter server for running code in vscode.dev
- Jupyter Kernels and the Jupyter Extension