StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<p>I think the answer here is "it depends". </p> <ul> <li><p>If you have full unit test coverage on the <code>FooToBarConverter</code> class then probably you are OK just with the integration test of <code>systemUnderTest</code> because you can say with confidence that the real <code>FooToBarConverter</code> behaves as expected in this context and therefore does not incorrectly influence the result of the test.</p></li> <li><p>On the other hand, it's unclear specifically what this test is checking for - are you examining the behaviour of <code>systemUnderTest</code> when given a valid <code>FooToBarConverter</code>, or some other expected side effect within <code>systemUnderTest</code> to which <code>FooToBarConverter</code> is a purely coincidental actor? (i.e are you sure that this isn't an indirect test of <code>bar</code>?)</p></li> </ul> <p>Now <em>personally</em> I would recommend that you also do a proper, "pure" unit test (using a mock or stub of <code>FooToBarConverter</code>) for <code>systemUnderTest</code> because </p> <ul> <li><p>it will make regressions easier to manage; suppose that in the future some change to <code>FooToBarConverter</code> makes its unit tests fail - they will quite possibly also therefore make this integration test fail. That could be confusing for someone looking at failed tests and not knowing that the integration test failure can be ignored and that only the FooToBarConverter tests need to be fixed. It's a small thing, I know, but it might save 5 important minutes some day :)</p></li> <li><p>How do you test the negative cases (behaviour of <code>systemUnderTest</code> when given a broken/invalid/null <code>FooToBarConverter</code>)? Since you'll probably have to write unit tests with stubs/mocks for these kind of cases anyway, you might as well have a unit test for the good case in the same project/test class as well, it's much clearer - otherwise you have to aggregate code coverage across both unit test and integration test projects to verify that <code>systemUnderTest</code> is fully covered...</p></li> </ul> <p>Also, don't worry about 100% code coverage; it's nice to have but in practice it's rare to see it. I don't mean this as a sop to good design practices either; the simple reality is that no design is 100% perfect and therefore it's to be expected that there are times when you just don't have the time/resource/will to refactor your classes to allow every single dependency to be injected, or to be able to use interfaces for every inter-seam interaction, etc.</p> <p>Hope that helps.</p>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload