Hello all, I recently wrote a library to solve a huge pain point of mine in JS: Mocking.
The current defacto tool `jest.mock` is a hammer -- it only lets you mock out entire modules and its limited to patching the interface of a module, if you wanted to change a detail within the implementation then you'd have to reimplement it and risk losing test coverage due to an unfaithful reproduction.
Contrastingly, JSPatch is a chisel. It lets you target any identifier at any scope level. Similar to what you can do using `mock.patch` in Python.
I'm hoping that this library will allow us to more easily draw boundaries around what we're testing. For example if you have a React component that uses a hook then normally you'll need to mock the hook via `jest.mock`. In the simple case this works fine but but it's still extremely tedious to setup and get right.
One of the cool benefits of the approach (code-transformation) is that modules that are patched get loaded lazily (if they end up unpatched in the test) leading to improvied test speed.
Hello It's Marco one of the developers. You're right, web workers absolutely have a spot in apps. That's actually why I thought to use them in the first place! In this case it turns out it wasn't necessary though. Sorry for the click bait title but I hope you could at least enjoy the article.
The current defacto tool `jest.mock` is a hammer -- it only lets you mock out entire modules and its limited to patching the interface of a module, if you wanted to change a detail within the implementation then you'd have to reimplement it and risk losing test coverage due to an unfaithful reproduction.
Contrastingly, JSPatch is a chisel. It lets you target any identifier at any scope level. Similar to what you can do using `mock.patch` in Python.
I'm hoping that this library will allow us to more easily draw boundaries around what we're testing. For example if you have a React component that uses a hook then normally you'll need to mock the hook via `jest.mock`. In the simple case this works fine but but it's still extremely tedious to setup and get right.
One of the cool benefits of the approach (code-transformation) is that modules that are patched get loaded lazily (if they end up unpatched in the test) leading to improvied test speed.
I'm looking for collaborators, feel free to open PRs, issues or discussion threads. https://github.com/salazarm/jspatch/