Ted M. YoungIn Test-Driven Development (#TDD), a RED test is only part of the story. Just because a test fails, doesn't mean that you're ready to write code to make it GREEN. Before you write that code, check that the test fails as it is SUPPOSED to fail.
Failing for the RIGHT REASON is a critical step, making sure you understand the current behavior of the system. If you ignore how it fails, you may find the code to make it green doesn't work: code somewhere else is behaving differently from your mental model.
This is why I do PREDICTIVE TDD and made it a core of JitterTed's TDD Game. It's saved me time troubleshooting the wrong problem. (On today's stream, this happened 5 times!)
Attending JCON Europe or COMO Camp? Save shipping: I can personally deliver it!
Jeff GriggYes.
*And Also*
Read the exception error message carefully.
Is it readable?
Easily?
Well formatted?
And, most importantly …
If/when it throws this months or years later, does it give us enough information to track down and fix the error without too much additional effort?
…
(And we didn't get the 'assertEquals' parameters in the wrong order again, did we? 🙄 )
Exactly. How can you tell if failed as desired/expected if you can’t understand the failure message.
And, as you say, later you won’t have the context you have now, so make it extra obvious what the failure is.
(Using AssertJ means one never gets assertion parameters out of order.)
Robert WatkinsAll new tests are supposed to fail. It's when they pass that you should get worried!
(But yeah, check that it's failing for the right reason...)
Deven Phillips@jitterted Another helpful practice I like to use is #MutationTesting to ensure that my test is ACTUALLY catching errors that it should catch.
@infosec812 Yep, mutation testing is great, but I’ve found if you’re doing TDD, it’s pretty boring as it almost always passes.