3 ms·

Sorry, I meant specifically unit testing. A good rule of thumb is that if you need heavy mocking to get unit testing done, you should probably just integration

Sorry, I meant specifically unit testing. A good rule of thumb is that if you need heavy mocking to get unit testing done, you should probably just integration and end-to-end test it. Example 1: typical machine learning training microservice. You query a pile of data from a few DBs, join it and process it, train a model on it and evaluate it. You could mock the DB queries to test it, but such a mocked unit test alone is dangerous (tests could pass when the relevant DB tables aren't updated correctly IRL) and doesn't add much of anything. Just integration and end-to-end test it. A machine learning inference service OTOH is much more natural to unit test. Example 2: you have an simple endpoint microservice with an internal caching structure (just for efficiency purposes). The "unit" here is still the user facing endpoint, trying to write unit tests for the internal caching structure will tightly couple your internal API between the caching layer and the API facing service. This makes refactoring harder for the service will adding little upside for what's useful overall here. You should unit test the cache THROUGH the unit tests of the endpoint service in this case if possible. SOLID people tend to cry at "unit testing through something else", but this is actually what Kent Beck really meant by "unit" in the original design (a unit is at the software system level, not in the implementation level of a class being a unit).

pseudoramble 5y ago
I'm glad you expanded on your previous answer. This is a take I've come to highly agree with. This even can apply to basic CRUD app work. For example, in a simple layered architecture that works like this: [Controller] -> [Service] -> [Repository] -> Actual DB I've found integration tests highly valuable at the Repository level. They've helped me not only catch bugs, but also guided me though migrating to a completely different DB. So, I am really happy with that choice. Unit test + mocks would have been of nearly zero value here. I've found DB-isolated tests beneficial at the Controller and Service layers. But keeping the tests for these two layers separate was kinda silly. Ultimately I want to know that the controller + service yields the result the consumer wants. For the sake of validating the logic in these classes, why would it matter if it took path A or B? If I had put these tests together, the ration of tests to lines covered would've been way less, with a relatively minor impact on readability.

pseudoramble 5y ago

I'm glad you expanded on your previous answer. This is a take I've come to highly agree with. This even can apply to basic CRUD app work. For example, in a simple layered architecture that works like this: [Controller] -> [Service] -> [Repository] -> Actual DB I've found integration tests highly valuable at the Repository level. They've helped me not only catch bugs, but also guided me though migrating to a completely different DB. So, I am really happy with that choice. Unit test + mocks would have been of nearly zero value here. I've found DB-isolated tests beneficial at the Controller and Service layers. But keeping the tests for these two layers separate was kinda silly. Ultimately I want to know that the controller + service yields the result the consumer wants. For the sake of validating the logic in these classes, why would it matter if it took path A or B? If I had put these tests together, the ration of tests to lines covered would've been way less, with a relatively minor impact on readability.