Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why Most Unit Testing Is Waste [pdf]

rbcs-us.com

Post reply on HN
Print view View original

31–40 of 159 posts

Re: Why Most Unit Testing Is Waste [pdf]

#31

Post by jononor »

juandazapata wrote: post #20

It'll be fun to refactor a codebase without unit tests

As long as there are suitable integration and system tests, this is no problem at all. Bonus if there are defensive assertions as recommended in the paper (design-by-contracts style). Sometimes it is easier to refactor a system without lots of unit-tests, as you need to update/fix lots of tightly coupled tests. What matters is what the system does (as seen from the outside), not how the underlying classes/functions work. They are mostly incidental.

Re: Why Most Unit Testing Is Waste [pdf]

#32

Post by dorfsmay »

fvdessen wrote: post #22
alfiedotwtf wrote: post #14

Earlier quoted context omitted.

This. We tend to put a high value on code review, yet some don't value unit testing. Lean in and I'll tell you a secret: ... unit testing is automated, repeatable, code review!

Only if the tests and business code are not written by the same engineer.

Which they typically no longer are when fixing a bug or refactoring.

Re: Why Most Unit Testing Is Waste [pdf]

#33

Post by RHSeeger »

crdoconnor wrote: post #17
henrik_w wrote: post #4

I disagree: https://henrikwarne.com/2014/09/04/a-response-to-why-most-un...

"In my experience, unit tests are most valuable when you use them for algorithmic logic. They are not particularly useful for code that is more coordinating in its nature." I agree in principle, but IME: * This kind of algorithmic code often makes up a fairly small proportion (~5%) of code written for most business driven applications - it's usually mostly coordination. Some domains may be different (and for them, un…

> Integration tests can test algorithmic acceptably well, but unit tests do not test integration code in an acceptable fashion.

True, but you can have both types of tests, which lets you test algorithms (unit tests) and higher level combinations (integration tests) both in the best way. The right tool for the right job.

> Where you have algorithmic and integration code smushed together (this type of technical debt is, sadly, the norm 'in the wild'), again, integration tests work acceptably well whereas unit tests require a mess of mocks.

In many cases, you'd be better off separating the logic, which would let you have both types of tests, each for a different part of the logic.

> Integration tests do not have to be high level or slow.

No, but they are a different tool.

Re: Why Most Unit Testing Is Waste [pdf]

#34

Post by vog »

fermigier wrote: post #24
fermigier wrote: post #23

This has already been discussed to death, on 3 occasions: https://news.ycombinator.com/item?id=7353767 (268 comments) https://news.ycombinator.com/item?id=11799272 (280 comments) https://news.ycombinator.com/item?id=13815779 ("only" 24 comments)

Also, there's a followup by Coplien which has not been discussed: https://rbcs-us.com/documents/Segue.pdf So maybe this document should be the focus of the discussion now.

I'd love to submit this document to HN, so it has a chance to get a wider audience than provided by this sub thread.

However, the title "Seque" is completely unspecific and hence totally useless. Given that title, I don't see how to submit this to HN in a way that it attracts readers.

This is really a pity.

Re: Why Most Unit Testing Is Waste [pdf]

#35

Post by mnsc »

bearjaws wrote: post #11
hacker_9 wrote: post #7

Earlier quoted context omitted.

Legacy code = code without tests. You might write HQ code today, but without tests it'll become technical debt within a month or even a week down the line. Programmers come and go, unit tests are omnipresent.

All code is legacy code as soon as you type the semi-colon. It is wishful thinking that a suite of unit tests will prevent a refactor or small change from producing technical debt.

In a sense you are right. That state where you have the complete program as a mental model goes away when you stop for that session. But if you pick it up the morning after that mental model could be reconstructed in < 1hr and you can finish the feature and deliver it as value to a user. If you created good tests (unit/integration/regression) that captures the gist of what the code should do, two-year-older-you or another developer have a good chance of getting a similar mental model in order to change the code with confidence. So i consider "legacy code" as a scale where you on one end go "The reqs have changed, better rewrite it all!" to "The reqs has changed, but I can confidently add this functionality and keep some of the unchanged behavior!"

Re: Why Most Unit Testing Is Waste [pdf]

#36

Post by jononor »

crdoconnor wrote: post #17
henrik_w wrote: post #4

I disagree: https://henrikwarne.com/2014/09/04/a-response-to-why-most-un...

"In my experience, unit tests are most valuable when you use them for algorithmic logic. They are not particularly useful for code that is more coordinating in its nature." I agree in principle, but IME: * This kind of algorithmic code often makes up a fairly small proportion (~5%) of code written for most business driven applications - it's usually mostly coordination. Some domains may be different (and for them, un…

For well-defined algorithmic logic, I'd say one is better off mostly using existing code (usually via a library). If a library does not exist, write the function as stand-alone with tests exercising its API. Preferably release it as open source.

Re: Why Most Unit Testing Is Waste [pdf]

#37

Post by mannykannot »

alkonaut wrote: post #27
mattmanser wrote: post #21

Earlier quoted context omitted.

The article addresses your first point in a big section: 1.4 The Belief that Tests are Smarter than Code Telegraphs Latent Fear or a Bad Process Your other point about only good programmers not needing unit tests is moot as you haven't followed it through to the conclusion. Namely, if bad programmers write bad code that needs unit tests, they're also going to write bad unit tests that don't test the code correctly. S…

My point was that even bad unit tests are better than both good/bad word docs or no unit tests. So even bad tests written by bad programmers have a value. They have a large COST too (which is what he's arguing), my argument was merely that the value might not be less than the cost, which is his assertion. > Software engineering research has shown that the most costeffective > places to remove bugs are during the tran…

The logical conclusion of this line of argument, which is dependent on the proposition that even bad unit tests have value, is that we could just automatically generate copious numbers of unit test cases for a given code base, and we would have something of value. In reality, this approach would be useless even for functionally-invisible refactoring or rewriting, precisely because it would be at the unit level. For that, let alone any substantive changes, Coplien's claim that higher-level tests are better stands, so this article cannot be dismissed as "beating a dead horse."

Re: Why Most Unit Testing Is Waste [pdf]

#39

Post by crdoconnor »

RHSeeger wrote: post #33
crdoconnor wrote: post #17

Earlier quoted context omitted.

"In my experience, unit tests are most valuable when you use them for algorithmic logic. They are not particularly useful for code that is more coordinating in its nature." I agree in principle, but IME: * This kind of algorithmic code often makes up a fairly small proportion (~5%) of code written for most business driven applications - it's usually mostly coordination. Some domains may be different (and for them, un…

> Integration tests can test algorithmic acceptably well, but unit tests do not test integration code in an acceptable fashion. True, but you can have both types of tests, which lets you test algorithms (unit tests) and higher level combinations (integration tests) both in the best way. The right tool for the right job. > Where you have algorithmic and integration code smushed together (this type of technical debt is…

>True, but you can have both types of tests

You can, but if your code is 95% coordination and 5% algorithmic, at most you'd want 5% unit tests.

>In many cases, you'd be better off separating the logic

Which is refactoring and if you're refactoring you need to have your code surrounded with tests to do it safely.

And, once you've done that, if you've already written integration tests for that logic and they perform acceptably well, there may be no point in rewriting the integration test as a unit test.

Re: Why Most Unit Testing Is Waste [pdf]

#40

Post by mannykannot »

alfiedotwtf wrote: post #14
alkonaut wrote: post #10

The normal practice for large scale codebases in complex domains is "the code is the spec". That is, the only specification for how the system should work is how it worked yesterday. In that case, unit tests serve as a great specification. Even tests that just duplicate the business code under test and assert that it's the same (A huge waste in normal cases) is useful. Because a Unit test is much better than a word d…

This. We tend to put a high value on code review, yet some don't value unit testing. Lean in and I'll tell you a secret: ... unit testing is automated, repeatable, code review!

How many times do you need to repeat the review of a given unit of code? (actually, that would have more chance of catching additional bugs than would rerunning the same unit tests.) Once you change the code, the existing unit tests are, by definition, invalidated (i.e. there is no value to being able to rerun them), while most higher-level testing will retain their validity. You have actually created an argument for automated higher-level testing (the author mentions that his position is often mistaken for an attack on test automation.)
Post reply on HN