Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> Test code doesn’t have its own test code, so the only way to verify correctness is by inspection.

This is about as incorrect as it gets.

The only way to verify correctness is to change the production code in a way that should cause the test to fail, then watch it fail. In TDD this is done by writing the test before you write the code that would make it pass, then watch it fail. Only then are you allowed to write the code that makes it pass.

Otherwise you have no proof the test can EVER fail - which means no proof it adds value to your codebase.



Thanks for reading!

>This is about as incorrect as it gets.

>The only way to verify correctness is to change the production code in a way that should cause the test to fail, then watch it fail. In TDD this is done by writing the test before you write the code that would make it pass, then watch it fail. Only then are you allowed to write the code that makes it pass.

>Otherwise you have no proof the test can EVER fail - which means no proof it adds value to your codebase.

I agree that changing the production code to cause a failure can be helpful, but I think it's an overstatement to call it "the only way to verify correctness." When I optimize for simplicity, I rarely encounter tests that pass in situations I didn't expect.

Also, forcing tests to fail doesn't really scale. You can do it initially as you write a new function, but once you commit your changes, whatever you've learned from the exercise evaporates. If you change the function or any of its dependencies, presumably you're not going to repeat the exercise of forcing each assert to fail one-by-one. According to what you're saying, that means that there's no longer proof that the test can fail.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: