4 ms·
I feel this can be summarised as "integration tests > unit tests". And yes. However, for tests you want to run locally and quickly, the question should be, can
by JulianMorrison 5y ago
I feel this can be summarised as "integration tests > unit tests". And yes.
However, for tests you want to run locally and quickly, the question should be, can you get the speed advantage of unit tests with the largest possible amount of integration? Can you only mock things that are "outside the system" (such as DB, networked services, and file system)?
IMO the biggest risk of integration testing is non-cleanup. I feel that is one of the major positive use cases for mocking. A mock DB will not retain garbage from previous tests, or previous runs of the same test.
- 0xbkt 5y agoContainers do a good job on this. One should check out the Testcontainers[1] project that makes a good use of containers in language level. [1] https://github.com/testcontainers/testcontainers-go https://github.com/testcontainers/testcontainers-go
- JulianMorrison 5y agoThey can do a good job, but you need to be very careful. "Oh, it's faster if you start the container once and then run all the tests in it." Yeah but now your tests are all peeing in each other's pool. The upside of mocks is that the values returned are literally hard coded.