New answers tagged

3

Some relevant guidelines: The goal is confidence, not coverage. If you have good coverage with well-written unit tests then a tiny number of high-level tests can be enough to have confidence that the overall system will Just Work™. Having both unit and integration tests for the same functionality is a waste of time in terms of writing the tests, maintaining ...


1

Consider not using 'code coverage' as your metric Because systems and integrations have different issues and failure points it is hard to measure code coverage across systems. Code coverage, even for unit tests is a very rough guide and in my experience ends up, in reality being: You have to meet a metric, say 80% to get your code merged. This leads to low ...


1

The way I see it is that integration tests are actually about integrating real stuff, not mocking. It makes sense to mock other components in your unit tests, because you are focused on your component you're implementing, so you want to filter out yet another complexity in the form of those other components, or those other components might not be implemented ...


Top 50 recent answers are included