Timeline for How do you detect dependency problems with unit tests when you use mock objects?
Current License: CC BY-SA 3.0
9 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Apr 1, 2018 at 20:25 | comment | added | Andrew T Finnell | @MatthieuM. I’d argue this is beyond the scope of Unit Testing. The glue code can be unit tested itself while the interactions between A and B via the glue code is an Integration Test. When specific edge cases or bugs are found they can be added to the glue code unit tests and ultimately verified in Integration testing. | |
| Mar 28, 2018 at 18:22 | comment | added | Fabio | @Eternal21 the beauty of unit tests you talking about will be gone, when you start refactoring or for example want to extract some functionality from B, because your unit tests will fail. | |
| Mar 28, 2018 at 17:09 | comment | added | millimoose | The state of the rest of the system is an implied input to A unless you mock up all possible states of its dependencies, unless most of your system is stateless to a fault. (In which case, great, but there’s other scenarios for testing other than “we’re doing it all right” greenfield development.) | |
| Mar 28, 2018 at 11:53 | comment | added | Matthieu M. | @Eternal21: My point was that sometimes, the problem is not in the individual behavior, but in an unexpected interaction. That is, when the glue between A and B behaves unexpectedly in some scenario. So both A and B act according to specifications, and the happy case works, but on some inputs there's a bug in the glue code... | |
| Mar 28, 2018 at 11:39 | comment | added | Eternal21 | @MatthieuM. If A is unit tested for all possible inputs, and B is unit tested for all possible inputs, then a single integration test, to make sure that the two interact properly is sufficient. That's the beauty of unit tests. Sure, you may want to add another one or two, to ensure proper handling when object B is null (if for example you are injecting it in A via constructor). | |
| Mar 28, 2018 at 9:09 | comment | added | Matthieu M. | I disagree with the idea that a single integration test is sufficient if you want full coverage. The reactions of B to what A outputs will vary based on the output; if changing a parameter in A changes its output, then B may not handle it correctly. | |
| Mar 27, 2018 at 21:22 | comment | added | Richard Tingle | Right, but nowhere does your 20 unit test's require mocking. If you have your 10 tests of A that cover all of A and your 10 tests that cover all of B and also retest 25% of A as a bonus this seems between "fine" and a good thing. Mocking A in Bs tests seems actively stupid (unless there really is a reason why A is a problem, e.g. it's the database or it brings in a long web of other things) | |
| Mar 27, 2018 at 13:00 | comment | added | Robbie Dee | I'm sure it is no coincidence that the question mark over the efficacy of integration tests has gone hand in hand with unit tests covering every more layers. | |
| Mar 27, 2018 at 12:22 | history | answered | Eternal21 | CC BY-SA 3.0 |