Verification-First Development(buttondown.com) |
Verification-First Development(buttondown.com) |
Unfortunately this article appears to want to treat TDD as a sub-set of TFD. I'd like to redefine TDD to mean "you bundle tests with your implementation when you commit to source control" - where it doesn't matter if you wrote the tests before or after the implementation.
I write a lot of my tests after, often using snapshot testing. I get the key benefits of a robust test suite - protection against future changes introducing bugs that my test suite would have caught - but I don't go through the torment of trying to figure out how to test something that I've not yet even fully designed.
Although I'd like to think telling people that they should have tests requires an acronym in 2025.
It's critically important to very carefully review the snapshots before committing them for the first time though - it's far too easy to run the test, look at the output, think "yup that looks like some sql/assembly/whatever that does the thing I'm trying to do" and carry on. Only to realize days/weeks/months later that there's a bunch of bugs that you never caught because your supposed "correct" output was never actually correct.
What? The whole point of TDD is that you design the thing by writing the tests. That's why it's called Test Driven.
My main challenge is that I don't know what to call the tests I write, or the process that I use. Calling them "tests" can be confused with manual testing. I usually call them "automated tests" but it's a mouthful and not a term I hear from other people.
I dont see a reason to write the test before code even though the snapshot needs to be generated after the code.
If you define the snapshot as being separate from the test (which conceptually it is) then STDD becomes just a variant of TDD.
Same idea, different spelling: do you really think TDD should get credit for your good results, when you aren't actually shackling yourself to the practices that the thought leaders in that community promote?
Get validation team as an addition to your own tests.
You start with specification and both teams - dev and val start developing parallelly.
They'll develop their own tests, then review your code with huge focus on finding bugs, security issues and so on.
Should not the verb be "to embuggen", the participle being "embuggening"?
It’s just too easy to update the snapshot, and when you glance at changes to a large snapshot, it’s impossible to tell what the test is actually trying to check
Aha, they are! I like the V-Model. It's not Move-Fast-And-Break-Things style.