Hacker News Reader

Comment by brudgers | Hacker News Reader

When you think you understand something write a test and test your belief. If the test passes then both your knowledge and the code base are better for it. If the test fails then rewrite the test to the failure and write another test. Again you will know more and the code base will be better.

Good luck.

View on HN

I feel your comment should be the top one. but I disagree with this bit:

> the code base will be better.

I'd change "will be" to "might get." because this is true if you're doing unit tests that the code base can use. but sometimes you do characterization tests, which are not worth keeping around. or you might build a couple variations on "hello world" with the unfamiliar code base, just to be sure that it works the way you think it does.

When writing a test exacerbates a too-many-tests problem, it's both a rare and and good problem to have because reading and running such tests is a more expeditious route to understanding than writing tests in the blind.

What if you wrote a test that passes at the time of writing because of how something is implemented at that time but its not actually an invariant?

Then you will learn that later when the test fails. That is better because the reason for writing the test was your belief that it was invariant. Without the test you are more likely to continue holding the mistaken belief.

Sure, but that is an incorrect test for other developers to worry about it failing.

Reply on news.ycombinator.com