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
Copy file name to clipboardExpand all lines: docs/contributor/writing-tests-for-vscode-swift.md
+39Lines changed: 39 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -12,6 +12,7 @@ A brief description of each framework can be found below:
12
12
13
13
-[Organizing Tests](#organizing-tests)
14
14
-[Writing Unit Tests](#writing-unit-tests)
15
+
-[Mocking the File System](#mocking-the-file-system)
15
16
-[Mocking Utilities](#mocking-utilities)
16
17
-[Mocking interfaces, classes, and functions](#mocking-interfaces-classes-and-functions)
17
18
-[Mocking VS Code events](#mocking-vs-code-events)
@@ -113,6 +114,44 @@ suite("ReloadExtension Unit Test Suite", () => {
113
114
114
115
You may have also noticed that we needed to cast the `"Reload Extensions"` string to `any` when resolving `showWarningMessage()`. Unforunately, this may be necessary for methods that have incompatible overloaded signatures due to a TypeScript issue that remains unfixed.
115
116
117
+
## Mocking the File System
118
+
119
+
Mocking file system access can be a challenging endeavor that is prone to fail when implementation details of the unit under test change. This is because there are many different ways of accessing and manipulating files, making it almost impossible to catch all possible failure paths. For example, you could check for file existence using `fs.stat()` or simply call `fs.readFile()` and catch errors with a single function call. Using the real file system is slow and requires extra setup code in test cases to configure.
120
+
121
+
The [`mock-fs`](https://github.com/tschaub/mock-fs) module is a well-maintained library that can be used to mitigate these issues by temporarily replacing Node's built-in `fs` module with an in-memory file system. This can be useful for testing logic that uses the `fs` module without actually reaching out to the file system. Just a single function call can be used to configure what the fake file system will contain:
122
+
123
+
```typescript
124
+
import*aschaifrom"chai";
125
+
import*asmockFSfrom"mock-fs";
126
+
import*asfsfrom"fs/promises";
127
+
128
+
suite("mock-fs example", () => {
129
+
// This teardown step is also important to make sure your tests clean up the
130
+
// mocked file system when they complete!
131
+
teardown(() => {
132
+
mockFS.restore();
133
+
});
134
+
135
+
test("mock out a file on disk", async () => {
136
+
// A single function call can be used to configure the file system
In order to test failure paths, you can either create an empty file system or use `mockFS.file()` to set the mode to make a file that is not accessible to the current user:
147
+
148
+
```typescript
149
+
test("file is not readable by the current user", async () => {
This section outlines the various utilities that can be used to improve the readability of your tests. The [MockUtils](../../test/MockUtils.ts) module can be used to perform more advanced mocking than what Sinon provides out of the box. This module has its [own set of tests](../../test/unit-tests/MockUtils.test.ts) that you can use to get a feel for how it works.
0 commit comments