Why Most Unit Testing Is Waste [pdf]
rbcs-us.com
Why Most Unit Testing Is Waste [pdf]
1–10 of 159 posts
Re: Why Most Unit Testing Is Waste [pdf]
#2This is such a great document. I have referred to it quite a lot in my last job as we were restructuring our test. We mainly had unit tests that we'd just try to make green every time after changing code. It didn't stick well with me that we'd just rewrite the code in a different syntax (Rspec DSL). You don't really test anything in that way.
Just be prepared for a lot of shocked reactions when you say 'Most Unit Testing Is Waste' to people who have not been softened a bit to this concept.
I really like this way of thinking. The next chapter of getting into this subject are the live discussions (5 videos) between Kent Beck, David Heinemeier Hansson and Martin Fowler talking about TDD (which relies a lot on unit tests): https://martinfowler.com/articles/is-tdd-dead/ I enjoyed these a lot too and the combination of these sources has really improved my testing.
Re: Why Most Unit Testing Is Waste [pdf]
#3In my experience the usefulness of Unit Tests is very dependent on the quality of the team and its grasp on the business requirements. Some programmers can write high quality code that doesn't need unit/integration testing at all, some can't.
Re: Why Most Unit Testing Is Waste [pdf]
#4Re: Why Most Unit Testing Is Waste [pdf]
#5not only is it often waste but it can tremendously add to code bloat and 'dept'. I saw a dev spending 80% of his time 'fixing test setup' instead of fixing code.
Re: Why Most Unit Testing Is Waste [pdf]
#6I disagree: https://henrikwarne.com/2014/09/04/a-response-to-why-most-un...
This. A thousand times this. The debate about testing should stop being about what type of testing os the best and start being about what type of test to use where.
Re: Why Most Unit Testing Is Waste [pdf]
#7In my experience the usefulness of Unit Tests is very dependent on the quality of the team and its grasp on the business requirements. Some programmers can write high quality code that doesn't need unit/integration testing at all, some can't.
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.
Re: Why Most Unit Testing Is Waste [pdf]
#8I pretty much agree with all of this.
Unit tests are great when you have a large code base with dozens of apps and need to modify a core library to remove side effects. How do you know you didn't break one of the apps?
But if we go deeper, why does the core library have side effects? Because it was a crummy, poorly designed piece of crap to begin with. If it was originally written with high quality it wouldn't need the refactor now. The author noticed this. He wrote good code to begin with so it didn't need a lot of testing.
When you have a large team of mediocre engineers you need unit tests to guard against more bad code from getting in. They might even be brilliant engineers, stuck in a horrible process of churning out features to unrealistic deadlines.
If you have a great team, a great process, and a great budget with realistic goals, you can crank out amazingly good software without the need for a lot of unit tests. But that's not the real world. In the real world we have lots of unit tests. They are a band-aid over the other problems without addressing them specifically.
Re: Why Most Unit Testing Is Waste [pdf]
#9This is clearly an opinion-piece and as such I guess it's not terrible, but it certainly has enough points to disagree with.
From quickly reading through it, for instance I found the following things directly objectionable:
> "Unit testing was a staple of the FORTRAN days".
Such an attempt at discrediting something can be applied to anything, and it comes off as disingenuous, dishonest.
> "Unit tests are unlikely to test more than one trillionth of the functionality of any given method in a reasonable testing cycle. Get over it." ... Trillion is not used rhetorically here, but is based on the different possible states given that the average object size
Who says you have to test the method? Who says you're not allowed to test functions which operate on a known, closed subset of data?
False dichotomy and plain bad math.
> If you find your testers splitting up functions to support the testing process, you’re destroying your system architecture and code comprehension along with it.
That may be right. Or it may be possibly completely backwards. It's quite impossible to tell really, without asking why they are splitting up those functions.
If people do this for gaming some sort of system about "at least 80% coverage" or whatever, then clearly you should ask why people feel the need to game the system. Gaming the system, no matter what aspect, leads to bad choices.
Me however, I'm not splitting up my functions to game the system. I'm splitting up my system to separate data-retrieval from data-processing (so I can directly test processing without depending on whatever retrieval depends on).
I'm splitting up my functions to give them name and intents, this makes the code speak much clearer about what it is doing and why. The function name should be "what". The contents should be "how".
Basically I'm splitting up my function for good reasons.
If a function is long enough to contain enough actions, intermediate variables, loops and conditionals so that you need to stop thinking about and wonder what they do, and what their role is inside that function... That functions should be split up, because you do not have a clear "what" and "how" delimiter.
And guess what? That also assists testability. You can test that the "how" correctly assesses the "what".
This is not destroying your system.
Some of the functions you end up with may even turn out to be reusable across the class/system, meaning you increases consistency and correctness as a result too.
Again: This is not destroying your system. Quite the opposite.
I could go on, but I'm just at the 4th page of 21, and my comment is already the biggest in the thread, and I'm not planning on making a blog-post length response.
Just saying this document is severely biased, contains factual errors and is not a good thing to rely on to present an argument.
Re: Why Most Unit Testing Is Waste [pdf]
#10The 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 document in describing how code should behave. I very much prefer a massive, hard to maintain set of poorly written unit tests, to a large number of outdated documents describing how every bit of the system should work.
So is a big/bad test suite a burden? Sure. But is it a burden compared to maintaining specifications of other kinds? Is it a burden compared to working in a system with neither type of specification?
Further, the people writing long articles like this are (or at least were) very good developers. There is often an element of "good developers write good code, so just use good developers" in them. But writing good software with good developers was never the problem. The problem is making software that isn't terrible, with developers ranging from good to terrible, and most being mediocre.