JS: Advanced Testing
2026-02-21 02:51 Diff
https://hexlet.io/courses/js-advanced-testing/lessons/files/theory_unit

The most typical side effect is interacting with files (file operations). This is essentially either reading files or writing to them. Reading is much easier to deal with, so that's where we'll start.

Reading files

In most cases, reading files isn't too much trouble. It doesn't change anything, and it's executed locally, unlike network queries. This means that if you have the correct file and the correct rights, the probability of accidental errors is extremely low.

When testing functions that read files, there's one condition that must be met. The function must allow you to change the path to the file. In this case, it's enough to create a file with the desired structure in the fixtures.

You can't read /etc/passwd in tests because the contents of this file depend on the environment in which the tests are run. To test, you need to create a file with a similar structure in the fixtures and specify it when you run the function:

Writing to files

Writing to files is more complicated. The main problem is the lack of guaranteed idempotency. This means that a repeated call to a function that writes files may not behave like the first call, for example, it may end with an error or lead to different results.

Why? Imagine we're writing tests for the log(message) function, which adds all messages sent to it to a file:

This means that each test run will be slightly different. The first time you run the tests, a file is created to store the logs. Then it will start to fill up. This leads to a whole bunch of problems:

  • The file creation process within this function will be a special case that needs to be tested separately. Running this test repeatedly will mean this situation will no longer be tested.
  • It's harder to write a predictable test. You'll have to come up with additional tricky schemes, such as checking only the last line in the file. This approach lowers the quality of the test.
  • This isn't particularly critical, but it's still worth noting: while tests are running, a file will appear that constantly grows in size.

If the tests are properly organized, each test will run in an identical environment each time. To do this, one option is to delete the file after each test. Jest has an afterEach hook that runs after each test. You can try using it to solve your issue.

In most situations, this solution works fine, but not all the time. Executing test code is not an atomic operation. There's no guarantee that the afterEach() hook will execute. There are many reasons why this may not happen, ranging from a sudden power outage to errors in Jest itself.

The only reliable way to do a cleanup is to do it before the test, not after, using beforeEach() There's only one small difficulty with this approach. When you run the tests for the first time, there won't be a file. This means that calling unlink() directly will end with an error and the tests won't be able to be executed. To avoid this, you can suppress the error:

There is another issue that can arise when writing files: Where do you save them? You should absolutely avoid writing files directly inside the project. If the code under test allows you to configure a write location, then use the system's temporary directory. It can be obtained via the os module:

Virtual file system (FS)

This is another way to test code that works with an FS. A virtual file system is created during tests using a special library It automatically substitutes the real file system for the fs module. This means that the function being tested must not be touched. This function still thinks that it's working with the real disk. The entire configuration is set from the outside, however:

This method gives you the idempotency out of the box. The mock function call generates an environment for each startup from scratch. That is, just add it to the beforeEach, and you can start testing.