I had never thought about calling a single method on the SUT multiple times as duplication. I'll have to spend some more time thinking about that.
Perhaps I should write this up somewhere. ?The usual example I give when teaching is using Java and moving a method from a static call no a non-static call. ?The test suite now needs to be updated in multiple places, hence the duplication.
If the entire test is written up front, and a new class is under development, that test will fail because of a failure to compile. The author could in theory, write lots of production code and then see the test "pass" without ever having seen it fail for the expected reasons. I would hope that wouldn't happen, but not having seen the full development progress or the progression taken it's a concern that I have.
I get you now. ?In my head I see this as two forms of failure, compilation failure and runtime failure. ?I won't even run the test if the compiler is complaining*. ?The key here really is to always see the test fail /for the right reason/, i.e. the diagnostic output of my assert. ?It's good practise to ensure your diagnostics messages convey all the information you want them to at this point anyway.
* At least in a language/IDE that offers good support?
