Mockshot – automatic mock generation from snapshot tests ↦
We made a silly joke on Twitter yesterday (this is what Twitter is for, no?) about test doubles and that unfortunate moment when they inevitably surprise you.
This prompted Shlomo Kraus to reach out and tell us about Mockshot. In brief:
Imagine you could:
- Never manually write a mock again
- Have a guarantee that your mocks are always valid
Sounds nice! It works by using Jest’s snapshot tests output to generate mocks to be used in other tests.
This is purposeful coupling, which seems like it could backfire in the long-run. However, the team behind the library has been using it for over a year and are still singing its praises. For more on their experience creating and using it, read this.
Discussion
Sign in or Join to comment or subscribe
Shlomo Kraus
2019-03-19T16:48:06Z ago
Thank you guys for publishing our project!
Not only that it won’t backfire in the long run, but it actually enhanced our delivery cycle significantly. Here’s why:
We have a huge code base with 100s of packages. We have a test coverage of around 80%, yet we have very few e2e and integration tests.
I know what you’re thinking - unit tests coverage is just a vanity metric. And you are correct. But since we are using a methodology called “test coupling” using mockshot, our unit tests have the same power of integration tests. That means we can have a (near) complete system check in less than 6 minutes, vs 40 minutes if we used classic integration tests.
I invite you all to read more about it in the attached medium post: (https://medium.com/iqoqo-engineering/this-library-uses-your-jest-tests-to-generate-mocks-c07c322c58e3)
In an ultra-short scope, it works like this -
a service class is generating a mock of itself, then it is asserted against its own mock. This mock is then used in any other class that requires this service. So now if the original service changes, it will break the tests that assert against its mock. Fixing the tests will require updating the mock and at that point, the change will propagate to any other objects using this mock, and so on. This chain reaction acts as an integration test, making sure all interfaces are aligned.
I can tell you that I’ve personally changed core features in our system and was able to quickly push the change just by updating the tests. Again, without any need to run the system e2e.
(of course, this doesn’t give complete coverage, and we do have some e2e and integration tests, mostly ones that check complex state and features in the system, but we do not rely on them for the majority of our codebase).