Timeline for How do you detect dependency problems with unit tests when you use mock objects?
Current License: CC BY-SA 3.0
17 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Mar 31, 2018 at 19:29 | comment | added | BartoszKP | Testing business behaviour (instead of classes, as mentioned above) is perfectly possible with by-the-book unit-tests. Only the "unit" needs to be defined in a sensible way. Hint: "smallest piece of code that compiles in isolation" is not a sensible way of defining unit. Also, It's true that the answer is good, but doesn't answer the question: the same problem can be imagined for a dependency that must be mocked. | |
| Mar 29, 2018 at 15:21 | comment | added | 17 of 26 | I definite 'unit' as a handful of classes that get tested together as a unit :P. A test that tests a class with all of its dependencies mocked out isn't testing anything real. | |
| Mar 29, 2018 at 7:48 | comment | added | David Arno | @NickCoad, "Testing that two classes work appropriately together is an integration test". See the point is, I say you are wrong. Mocking out one of those classes in the mistaken belief that it's then a unit test leads to crappy tests that are of no use to anyone. So let's stop calling those crappy tests, "unit tests" and let's reserve the term for good quality, useful tests. | |
| Mar 29, 2018 at 3:31 | comment | added | Nick Coad | Testing that two classes work appropriately together is an integration test. This answer is not about unit testing and so I don't think it really answers the question very well. | |
| Mar 28, 2018 at 20:36 | comment | added | Robbie Dee | @Richiban There is a newer version of the talk here. I mostly agree although many of the flaws he identifies which went before boil down to bad process. | |
| Mar 28, 2018 at 19:37 | comment | added | Moo | @Richiban I agree with you and David - unit tests should be testing a specific behaviour assuming a perfect world (ie, that all dependencies do exactly what you expect them to - and you achieve that by unit testing them as well). Once you start assuming a non-perfect world, you are testing something else - which is fine, integration tests, end to end tests etc are all usable. | |
| Mar 28, 2018 at 17:54 | comment | added | Robbie Dee | @Darkwing Yep, it's happy path testing however one spins it. Something that'll be picked up by manual tests most of the time anyway. | |
| Mar 28, 2018 at 17:32 | comment | added | Frank Hopkins | This doesn't answer the question - if a test for X doesn't mock A, then it's also a test for A. But there is always an Y that you don't want to test with A, for which the question applies. Unless you only have full integration tests which seems weird and unmaintainable with a decent coverage for more complex projects. | |
| Mar 28, 2018 at 17:17 | comment | added | Robbie Dee | @DavidArno "some random definition of a word" - it really couldn't be clearer. Hell, it is even on the first line. Please do call them automated tests or whatever your mot du jour is and stop deliberately conflating concepts. The tag is unit-testing - not integration testing and not BDD. | |
| Mar 28, 2018 at 12:33 | comment | added | Richiban | I'm with @DavidArno on this one; my testing strategy changed after watching this talk by Ian Cooper: vimeo.com/68375232. To boil it down to a single sentence: Don't test classes. Test behaviours. Your tests should not have knowledge of the internal classes / methods used to implement the desired behaviour; they should only know the public surface of your API / library and they should test that. If tests have too much knowledge then you're testing implementation details and your tests become brittle, coupled to your implementation, and actually just an anchor around your neck. | |
| Mar 28, 2018 at 7:21 | comment | added | David Arno | @PhilFrost, to quote myself, "And if some folk get upset with you calling these tests, "unit tests", then just call them "automated tests" and get on with writing good automated tests." Write useful tests, not silly tests that simply meet some random definition of a word. Or alternatively, accept that maybe you have your definition of "unit test" wrong and that you are over using mocks because you have it wrong. Either way, you'll end up with better tests. | |
| Mar 27, 2018 at 23:53 | comment | added | Phil Frost | You're advocating for a different kind of test rather than answering the question. Which is a valid point, but this is a pretty underhanded way of doing it. | |
| Mar 27, 2018 at 22:42 | comment | added | Wildcard | Your comment above is echoing the "Fakes" section of the article, The Philosophy of Testing, which is a very worthwhile read. | |
| Mar 27, 2018 at 12:47 | comment | added | Robbie Dee | @DavidArno There is alas a very broad definition of isolated. Some would like a "unit" to include the mid-tier and the database. They can believe whatever they like but the chances are that on a development of any size, the wheels will come off in fairly short order as the build manager will throw it out. Generally, if they're isolated to the assembly (or equivalent), that is fine. N.B. if you code to interfaces then it is far easier to add mocking and DI later. | |
| Mar 27, 2018 at 12:36 | comment | added | David Arno | @Laiv, No, unit tests are supposed to act as a unit, ie run in isolation, from other tests. Nodes and graphs can take a hike. If I can run an isolated, side-effect free end-to-end test in a short time, that's a unit test. In if you don't like that definition, call it an automated test and stop writing crap tests to fit silly semantics. | |
| Mar 27, 2018 at 12:34 | comment | added | Laiv |
by If you have parts of your code using mocks of other parts of your code you mean mocking several dependencies within the same dependency graph? Following this analogy, if each node of the graph is a dependency, are not unit test meant to test nodes one by one? (implementation details aside)
|
|
| Mar 27, 2018 at 12:29 | history | answered | David Arno | CC BY-SA 3.0 |