You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
- Do not export `types` or `functions` unless you need to share it across multiple components
256
257
- Do not introduce new `types` or `values` to the global namespace
258
+
- Use proper types. Do not use `any` unless absolutely necessary.
259
+
- Use `readonly` whenever possible.
260
+
- Avoid casts in TypeScript unless absolutely necessary. If you get type errors after your changes, look up the types of the variables involved and set up a proper system of types and interfaces instead of adding type casts.
261
+
- Do not use `any` or `unknown` as the type for variables, parameters, or return values unless absolutely necessary. If they need type annotations, they should have proper types or interfaces defined.
Copy file name to clipboardExpand all lines: .github/instructions/vitest-unit-tests.instructions.md
+28-6Lines changed: 28 additions & 6 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -3,12 +3,34 @@ applyTo: '**/*.spec.ts'
3
3
description: Vitest unit testing guidelines
4
4
---
5
5
6
-
Guidelines for writing unit tests using Vitest. These tests are `*.spec.ts`
6
+
Please follow these guidelines when writing unit tests using Vitest. These tests are `*.spec.ts`
7
7
8
8
## Best Practices
9
9
10
-
- Use proper mocks when possible rather than ad-hoc objects injected as dependencies. For example, call `createExtensionUnitTestingServices` to get some mock services, and `IInstantiationService` to create instances with those mocks.
11
-
- If there is no preexisting implementation of a service that is appropriate to reuse in the test, then you can create a simple mock or stub implementation.
12
-
- Avoid casting to `any` whenever possible.
13
-
- When asked to write new tests, add tests for things that are interesting and nontrivial. Don't add a test that just verifies that a setter/getter work.
14
-
- Prefer the runTests tool to run tests over a terminal command.
10
+
- Prefer explicit Test/Mock classes over mutating real instances or creating adhoc one-off mocks.
11
+
- Never use `as any` to override private methods or assign properties on real objects.
12
+
- Mock versions of services are typically named `Mock*` or `Test*`, you can search to find whether one already exists.
13
+
- Some examples: `MockFileSystemService`, `MockChatResponseStream`, `TestTasksService`.
14
+
15
+
- If there is no preexisting implementation of a service that is appropriate to reuse in the test, then you can create a simple mock or stub implementation in a file under a `test/` folder near the interface definition.
16
+
- A mock class should be configurable so that it can be shared and set up for different test scenarios.
17
+
18
+
- The helper `createExtensionUnitTestingServices` returns a `TestingServiceCollection` preconfigured with some common mock services, use `IInstantiationService` to create instances with those mocks. Here's an example of using it properly
- When asked to write new tests, add tests to cover the behavior of the code under test, especially things that are interesting, unexpected, or edge cases.
28
+
- Avoid adding tests that simply repeat existing tests or cover trivial code paths.
29
+
30
+
- If available, prefer the runTests tool to run tests over a terminal command.
31
+
32
+
- Keep tests deterministic and fast.
33
+
- Avoid starting real servers or performing network I/O.
34
+
35
+
- Avoid excessive repetition in tests, use `beforeEach` to set up common state.
36
+
- Use helper functions to encapsulate common test logic.
0 commit comments