Skip to content

Latest commit

 

History

History
76 lines (57 loc) · 5.45 KB

tests.md

File metadata and controls

76 lines (57 loc) · 5.45 KB

Tests

Introduction

There are several kinds of tests for the VS Code Extensions. This document describes them and gives pointers on how to run/debug them.

The test types from most preferred to least preferred are:

  1. Unit Tests - jest: Found under the test/jest directory.
    • npm run test:unit
  2. End to End Tests - TDB

Deprecated

  1. Unit Tests - mocha: Found under the test/unit directory. Not under active development.
    • npm run test:unit
  2. vscode-integration - Tests that are somewhere between integration and unit tests. These are being phased out and there should be no new additions.
    • Close all instances of vscode.
    • npm run test:integration
  3. system-tests - These have been disabled for a long time and will soon be deleted.

To run all tests, execute npm run compile && npm run test from the root folder. Note the compile is only necessary for the integration tests.

Unit Tests

Unit tests priorities are as follows:

  1. Unit tests should focus on only the unit of code under test.
    • 1 method/function
  2. All dependencies should be mocked.
  3. Unit tests should be easy to write and execute
    • If your code is hard to test consider how it could be refactored to make it easier to test.
  4. Use only jest and do not import mochi/sinon/chai.
  5. Code coverage is one measure of how well we are unit testing our code. We should strive to cover all code paths for any touched code in the repository. Code coverage can be generated by including the --coverage flag to jest when executing.
    • Example of running jest includeing coverage generation jest --coverage

How to Write Jest Unit Tests

  • Test files use the {fileUnderTestName}.test.ts format and should go under the same directory structure as the source in the test/jest folder.
    • Note this is to separate from the existing mocha unit tests and enable us to track our progress for moving off mocha to jest.
    • Example:
      • File under test: src/commands/auth/authParamsGatherer.ts
      • Test File location and name: test/jest/commands/auth/authParamsGatherer.test.ts
  • VSCode extensions are our friend
  • Tests can be executed from the IDE, command line, or via npm script.
    • IDE: assuming you are using the above extension, use the Run & Debug CodeLens found in test files.
    • Command line: npx jest will execute all unit tests in a package by default. If the integration tests are configured for jest in the package you may execute those using npx jest -c jest.integration.config. There are many options for configuring the test run see the docs or npx jest -h for further guidance.
    • npm scripts:
      • npm run test:unit
      • npm run test:integration
      • npm run test

Jest Information

  • ts-jest enables us to compile on the fly so no need for compilation while writing unit tests.
  • Jest Docs are very good.
  • There is a shared top level jest config file for unit and integration tests. The unit test configuration is shared between the exisiting tests in the unit directory and the tests in the jest directory.
    • Each module requires a jest.config.js configuration file that extends the shared base configuration file. If you add initial jest tests to a package be sure to create one or the jest tests will not execute properly. Any package specific jest configuration can be configured in the package level file. See Configuring Jest.
  • There is a top level jest setup script setup-jest.js where we are mocking the vscode module.
  • Jest is automatically injected into the tests so we don’t need to worry about importing jest, expect, etc.
  • Jest is currently configured to resetAllMocks after each tests. Unit tests should never have dependencies on the execution of other tests. This ensures that we don't have to manage restoring or resetting mocked values in individual test or suites of tests.

Virtual Mocked vscode Module

Making use of the ability to have mocked virtural modules in jest enabled us to stub out the vscode module for unit tests. This is required due to vscode extensions only having the @types/vscode module installed locally during development. The vscode module is only available when executed on a running instance of vscode.

The mock is defined in setup-jest.js and is automatically injected for all tests.

Best Practices around the mocked vscode modules.

  • If you find a property that is not currently available in the mock please add it.
  • The mocked module should only mock the high level properties. Resolving/returning values should be left to the individual test suite setup so that we can avoid having to adhere to particular behavior across tests.
  • Be aware that the mock call is only executed once during test execution and then resolves for all imports executed during the test run. Individual mocked properties on the module are reset after each test.