May 14, 2014 (updated June 18, 2019) Simple Design, Test Doubles
This is a companion discussion topic for the original entry at http://blog.thecodewhisperer.com/permalink/the-curious-case-of-tautological-tdd
This is a companion discussion topic for the original entry at http://blog.thecodewhisperer.com/permalink/the-curious-case-of-tautological-tdd
downloading is fine, the link doesn't work however
It has worked for hundreds of people so far, so perhaps you need to try again. It's a public link to a file in Strongspace, in case that gives you an idea why it might not be working.
great write-up J.B.
Do you have a post where you go into "deep philosophical argument" of why you would use two tests instead of one?
No. The argument is perhaps more dogmatic than deep, but not long. Let me draft it here, and we'll see whether it expands into its own article.
I want to check two things: (1) the Service answers to its clients the same Collection of Cars that it gets from the Repository; (2) the Service uses the service header from the Supplier in order ask the Repository for all the Cars.
Test 1 checks a return value and test 2 checks a method expectation. In principle, I could change these things independently; therefore, I "ought" to test them separately. The assertions (the return value is correct; the expectation is correct) are unrelated; therefore, I "ought" to check them separately.
I would check these two behaviors separately precisely because the guideline "check one thing in each test" has helped me identify so many design risks in the past, and maybe I just don't yet see the design risk that this test is alerting me to. I don't know yet.
That's the entire argument. I would tend to write one test, but be prepared to split it into two tests later, when I want to change one aspect of that behavior without changing the other.
Thank you. I am trying to reconcile different sources of information and I was wondering if your thinking had changed. In your WBTDD course you are using a single test with conditional stubs and use the conditions to define the contract tests. This single test also up matches with Mark Seemann's post Mocks for Commands, Stubs for Queries where he shows obviously degenerate code passing the two tests. But the book "Working Effectively with Unit Tests" has a lot of good information but prefers the two tests over one, and recommends a mixture of solitary (stubbing) tests and socialable (integrated) tests.