undefined | Better HN

0 pointsastrange5y ago0 comments

It is kind of a bad thing. Recently at work there was a quality program introduced by some training guy, but by quality they seemed to mean write more tests and do TDD, and our junior engineers read that as write a ton of unit tests (the only kind they'd heard of.)

I pointed out the 10 year old Norvig vs Ron Jeffries fight[1] which demonstrates that TDD is useless when you don't already know what you're writing, but they just looked confused.

The other problem here is that unit tests never break (since you've mocked everything that can break) and therefore aren't worth running; it might be more productive to write them for TDD and then just not commit them.

[1] https://news.ycombinator.com/item?id=3033446

0 comments

6 comments · 4 top-level

bluGill5y ago· 2 in thread

Unit tests do break once in a while. 80% will never break once written and should be thrown away, but that other 20% will unexpectedly break in the future alerting you to a problem that otherwise you wouldn't find until much latter in the release cycle. I don't know have any way to know which tests are in the 20% and which the 80% to throw away, which is why I keep them all.

Of course the 80%/20% figures are estimates. The longer your code is maintained the more likely it is some tests will break.

karmelapple5y ago

Can confirm. Recently had simple unit tests that almost seemed, on first glance, to indicate, “huh, why are these tests here?”

Upgraded to NodeJS 12 where some details about sorting arrays were changed, and we got 2 failing tests. Before that, I would have bet money that those tests would never fail.

astrangeOP5y ago

Was that the point of the tests, or just a coincidence?

Now that they've failed once they've become regression tests (one of the most useful kind of test), but if you set out wanting to test the platform under you I think you'd want to do a lot more work than that.

1 more reply

blacktriangle5y ago

I agree with you, which is why I think the GPs post that TDD is not a dogma but another tool in your toolbox makes sense. Just like the larger development community when faced with new tools, individual developers go through the pattern of adoption where they start using a technique for everything (the honeymoon phase) and then through that phase they learn when the tool is appropriate and when the tool I not.

As posters in your linked thread point out, the irony is that Norvig would have probably been better off using TDD since he knew the general shape of his solution already where Jeffries likely should have been writing several spikes to explore the solution space rather than using TDD since he was unfamiliar with the problem and did not yet have a good solution.

solipsism5y ago

That's fine for code that never changes, or that has no logic in it. As soon as you want to change some code, you'll want a portion of the tests to require modification and a portion to stay passing.

8note5y ago

Unit tests that don't break are documentation, both about your code, and what you expect dependencies to do.

Gives you something to compare against if the dependency changes its behaviour

j / k navigate · click thread line to collapse