Live data from Hacker News

Most Unit Testing Is Waste (2014) [pdf]

rbcs-us.com

1–10 of 164 posts

Re: Most Unit Testing Is Waste (2014) [pdf]

#3
This is very interesting, when you contrast it to [https://dl.acm.org/citation.cfm?id=3106270].

I'm always weary of arguments that rely on 'unit tests are more complex than the code'. If that's true, then it's correct. Tests have to encapsulate the software contract that's being enforced and should be more complex than the underlying code.

Re: Most Unit Testing Is Waste (2014) [pdf]

#4
My experience with testing is like that old adage about advertising, "I know I'm wasting 50% of my money but I don't know which 50%." Most of it is a waste but it's hard to know in advance which test will stop an engineer in a couple of years from altering some fundamental contract and bringing the system down.

Re: Most Unit Testing Is Waste (2014) [pdf]

#6
> If you want to reduce your test mass, the number one thing you should do is look at the tests that have never failed in a year and consider throwing them away. They are producing no information for you — or at least very little information.

I feel like there is some subtlety here that most will miss. Specifically, "and consider". That is the part we are really bad at.

Re: Most Unit Testing Is Waste (2014) [pdf]

#7

> If you want to reduce your test mass, the number one thing you should do is look at the tests that have never failed in a year and consider throwing them away. They are producing no information for you — or at least very little information. I feel like there is some subtlety here that most will miss. Specifically, "and consider". That is the part we are really bad at.

Those tests are helpful when you do major architectural changes, which may not happen every year.

Tests also help in general development. Make some changes, then fix the tests. If you are running tests locally on your machine (and offline) how can you be sure that every time a test fails locally the failure is logged?

Re: Most Unit Testing Is Waste (2014) [pdf]

#8
post #7

> If you want to reduce your test mass, the number one thing you should do is look at the tests that have never failed in a year and consider throwing them away. They are producing no information for you — or at least very little information. I feel like there is some subtlety here that most will miss. Specifically, "and consider". That is the part we are really bad at.

Those tests are helpful when you do major architectural changes, which may not happen every year. Tests also help in general development. Make some changes, then fix the tests. If you are running tests locally on your machine (and offline) how can you be sure that every time a test fails locally the failure is logged?

... and you don't always know what is a "major architectural change" that's going to break one of these tests, so you can't just relegate those tests into a category that is only run for major architectural changes.

Re: Most Unit Testing Is Waste (2014) [pdf]

#9
I got progressively more and more frustrated with this article, largely because he keeps making statements about the impossibility of covering all states a class may take on (true!) but then followed up with espousing more use of integration and system tests, which are clearly combinatorial harder to test “completely”. He also implied at the very beginning that somehow this was driven by the switch from FORTRAN to OOP, as if FORTRAN avoided this combinatorial explosion (magic!) and it’s only because of polymorphism that we live in the “unit testing is good” world.

The logical contradictions eventually overcame me.

Re: Most Unit Testing Is Waste (2014) [pdf]

#10
post #5

I've generally preferred integration tests to unit tests but Storybook has completely changed how I write React components, for the better.

Agreed on integration tests over unit tests. I get the most bang for my buck with them. Storybook is pretty nice. I use it for developing smaller components, more of the building blocks of the application. Have you ever checked out Kent C Dodd's react-testing-library? It was a refreshing approach to testing react components IMO and it has gained quite a bit of adoption.
Post reply on HN