>If you’ve ever heard someone claim that Test-Driven Development leads to zero-defects code
I havent. It's a lot more reliable, still not 100% reliable.
>If you can define the inputs, predict the outputs, and cover edge cases, TDD is like a superpower. But the real world is rarely that tidy.
shrug it ought to be that tidy if you specify your features before building them.
For writing code to test a sin function (a bit of a contrived example, but let's run with it) - well, that would be an excellent candidate for property test driven development because there are straightforward invariants you can define.
When edge cases crop up for other styles of code, well, talk about them with your PM and write test cases for them too.
If the spec is something like a UI which is visual and specified imprecisely with a sketch or something, snapshot test driven development more appropriate but that's still just a variant of TDD.
>If you’ve ever heard someone claim that Test-Driven Development leads to zero-defects code
I havent. It's a lot more reliable, still not 100% reliable.
>If you can define the inputs, predict the outputs, and cover edge cases, TDD is like a superpower. But the real world is rarely that tidy.
shrug it ought to be that tidy if you specify your features before building them.
For writing code to test a sin function (a bit of a contrived example, but let's run with it) - well, that would be an excellent candidate for property test driven development because there are straightforward invariants you can define.
When edge cases crop up for other styles of code, well, talk about them with your PM and write test cases for them too.
If the spec is something like a UI which is visual and specified imprecisely with a sketch or something, snapshot test driven development more appropriate but that's still just a variant of TDD.