re: Me: "I tested and it works, why do I have to write tests?" VIEW POST

TOP OF THREAD FULL DISCUSSION
re: In my opinion, tests are necessary but can also go to the extreme. The goal should be "write more stable code." with one of the strategies being w...
 

I've seen goals of "100% code coverage" which isn't really a goal.

True that. I've only gone for 100% test coverage for libraries, mostly pure functions. There are parts of code that may have a case for not being tested in actual projects.

It's fantastic when you're refactoring, protecting against regressions, and not having to jump through a bunch of manual testing steps

This exactly! One of the best moments was when I did an overhaul to a well-tested code, keeping the interface so that it is still within the specs but completely rewriting/improving the code, then seeing the tests passing still, that is such a wonderful feeling.

I also write tests for any specific bugs that crop up, again, regression protection.

Yes. IMO regressions are parts of code that we didn't cover, you could say that a particular area of the specification was missing. So it makes sense to make sure that it is covered by writing a test for it.

 

This exactly! One of the best moments was when I did an overhaul to a well-tested code, keeping the interface so that it is still within the specs but completely rewriting/improving the code, then seeing the tests passing still, that is such a wonderful feeling.

I came down to the comments to say this, you beat me to it hehe.

Tests used in this way are like the checkboxes you mentioned in the article. Even if you think you remembered all the use cases, there might be one that you came across before but forgot about during the refactor. If you wrote a test for that use case, the failing test would remind you of that case instead of a faulty build

code of conduct - report abuse