There is a subtle issue for which, unfortunately, neither ES6 nor proxyquire provide a solution. It is well described in this stackoverflow.com answer.
So far in the previous articles of the series, the dependencies we were mocking were in a separate module from the code we were unit testing. But what if they were in the same module?Read more →
In part one, I wrote about mocking ES6 module dependencies using the ES6 native
import * from construct. It works mostly fine. However, you need to be aware of a potential issue:
- You need to import modules to mock them, which means that those modules will be evaluated. That may be a problem if you don’t want the code in this modules to be executed.
Another method I found to work well is using proxyquire. It is one of many libraries aiming to streamline mocking dependencies to simplify unit testing.Read more →
Not so long ago I faced a problem: I needed to mock ES6 module’s dependencies for unit testing. The reason for mocking dependencies in unit tests is the following: when I write a unit test, I want to test the functionality of a single unit of code, hence a unit test. However, if a module has any dependencies, those dependencies need be satisfied. That may mean importing and executing code in other modules. As a result, the unit test loses its purity – the test results will depend not only on the module I’m focusing on but also on the other code my module depends on.Read more →