By Andrew Trenk This article was adapted from a Google Testing on the Toilet (TotT) episode. You can download a printer-friendly version of this TotT episode and post it in your office. Testing state means you're verifying that the code under test returns the right results. public void testSortNumbers() {numberSorter = new NumberSorter(quicksort, bubbleSort );// Verify that the returned list is sorted. It doesn't matter which sorting numberSorter .sortNumbers(new ArrayList(3, 1, 2))); Testing interactions means you're verifying that the code under test calls certain methods properly. public void testSortNumbers_quicksortIsUsed () {// Pass in mocks to the class and call the method under test. numberSorter = new NumberSorter(mockQuicksort, mockBubbleSort );numberSorter .sortNumbers(new ArrayList(3, 1, 2));// Verify that numberSorter.sortNumbers() used quicksort. The test should mockQuicksort ).sort(new ArrayList(3, 1, 2)); The second test may result in good code coverage, but it doesn't tell you whether sorting works properly, only that quicksort.sort() was called. Just because a test that uses interactions is passing doesn't mean the code is working properly . This is why in most cases, you want to test state, not interactions. interactions should be tested when correctness doesn't just depend on what the code's output is, but also how the output is determined . In the above example, you would only want to test interactions in addition to testing state if it's important that quicksort is used (e.g. the method would run too slowly with a different sorting algorithm), otherwise the test using interactions is unnecessary. What are some other examples of cases where you want to test interactions? The code under test calls a method where differences in the number or order of calls would cause undesired behavior , such as side effects (e.g. you only want one email to be sent), latency (e.g. you only want a certain number of disk reads to occur) or multithreading issues (e.g. your code will deadlock if it calls some methods in the wrong order). Testing interactions ensures that your tests will fail if these methods aren't called properly. You're testing a UI where the rendering details of the UI are abstracted away from the UI logic (e.g. using MVC or MVP). In tests for your controller/presenter, you only care that a certain method of the view was called, not what was actually rendered, so you can test interactions with the view. Similarly, when testing the view, you can test interactions with the controller/presenter.
Love this post. This topic of discussion seems to fall in with the Classical TDD vs Behavioral TDD debate, and I've thought that that argument usually just boiled down to what your post is about, testing state vs testing interactions.
ReplyDeleteWhen testing layers that don't make direct calls to the database, but perform them through data access objects, I usually mock them out to gain all the benefits of speed, reliability, and nimbleness (in terms of what branch statements I can hit) of unit tests. However, sometimes I wonder if it's better to just let those hit the database.