Why Most Unit Testing Is Waste [pdf] • Hacker News Board

Re: Why Most Unit Testing Is Waste [pdf]

#41

Post by alkonaut » Tue, Oct 31, 2017, 12:26 PM UTC

mannykannot wrote: post #37

alkonaut wrote: post #27

Earlier quoted context omitted.

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 t…

> 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.

I don't think that conclusion is any more valid than the proposition that if we just skipped the developer alltogether and generated both the business code AND the test, we'd have something of value.

> Coplien's claim that higher-level tests are better stands, so this article cannot be dismissed as "beating a dead horse."

i think higher level tests are good, but I don't think that makes lower level tests bad. I think there should usually be a health mix, with systems tested on several levels.

Re: Why Most Unit Testing Is Waste [pdf]

#42

Post by bonesss » Tue, Oct 31, 2017, 12:28 PM UTC

lmm wrote: post #28

josteink wrote: post #12

Earlier quoted context omitted.

> I pretty much agree with all of this. It's easy to disagree with someone who portrays an enemy which doesn't exist. I disagree with this piece everywhere it manages to land somewhere concrete, where its claims can be verified and assessed. > But if we go deeper, why does the core library have side effects Let's not get ahead of ourselves in theoretical, non-applied functional programming. As even Haskellers recogni…

Side effects are by definition outside the thing itself, so they're not really amenable to unit testing; you have to use integration tests.

Just... small point, but: side effects can be encapsulated, abstracted, and injected to create testable code in "side-effect" heavy situations.

Complex running dialog with a hardware serial device, for example, could be rearchitected as a component that has a clear-text dialog with a serial device proxy. This would create functional, side-effect free, testable units of code while also maintaining rich side effects in production (handled by pure integration tests).

Essentially: if you _have_ to use an integration test you should almost always be refactoring into something that you handle with unit tests in conjunction with your integration tests. Otherwise you're leaving maintenance developers with too much risk when making changes and no clear separation of your domain model from your application code.

Re: Why Most Unit Testing Is Waste [pdf]

#43

Post by abritinthebay » Tue, Oct 31, 2017, 12:31 PM UTC

Most unit testing is wasteful because most unit tests... are not unit tests. Or bad unit tests at least.

I can count on one hand the number of well written project test suites I’ve seen - even on code bases with 100% coverage.

We, as a group, do not seem to be good at writing them. I’m not sure why, and would love a discussion about it...

Re: Why Most Unit Testing Is Waste [pdf]

#44

Post by BlackFly » Tue, Oct 31, 2017, 12:32 PM UTC

lmm wrote: post #28

josteink wrote: post #12

Earlier quoted context omitted.

> I pretty much agree with all of this. It's easy to disagree with someone who portrays an enemy which doesn't exist. I disagree with this piece everywhere it manages to land somewhere concrete, where its claims can be verified and assessed. > But if we go deeper, why does the core library have side effects Let's not get ahead of ourselves in theoretical, non-applied functional programming. As even Haskellers recogni…

Side effects are by definition outside the thing itself, so they're not really amenable to unit testing; you have to use integration tests.

    class AccessCountedInteger {
        private final int value;
        private int accessCount = 0;

        AccessCountedInteger(int value) {
            this.value = value;
        }

        public int getValue() {
            accessCount++;
            return value;
        }

        public int getAccessCount() {
            return accessCount;
        }
    }

This unit has side effects on the method getValue() that impact what is returned by getAccessCount(). While it is contrived, if you are making something following the builder pattern, you will in general have a lot of side effects from all of the methods called on the final build() method. This is quite amenable to unit testing.

Re: Why Most Unit Testing Is Waste [pdf]

#45

Post by abritinthebay » Tue, Oct 31, 2017, 12:34 PM UTC

hacker_9 wrote: post #13

"my team told me the tests are more complex than the actual code. (This team is not the original team that wrote the code and unit tests. Therefore some unit tests take them by surprise. This current team is more senior and disciplined.)" Despite the inflammatory title, the point the PDF is making I believe is that unit tests should be kept short and simple, and convey the intent of your code. Intent is akin to the '…

Yes, I agree. Unit tests should test the smallest unit of work and build like LEGO bricks.

What the Article describes are tests but I would not call them unit tests.

Re: Why Most Unit Testing Is Waste [pdf]

#46

Post by brightball » Tue, Oct 31, 2017, 12:35 PM UTC

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…

That’s actually one of the reasons I like Elixirs approach to inline documentation so much. If you include a code example, the example is run as part of the test suite. Makes is dead simple to automatically include simple unit tests right where the code is along with documentation that had to remain up to date.

http://whatdidilearn.info/2017/10/23/writing-documentation-i...

Re: Why Most Unit Testing Is Waste [pdf]

#47

Post by abritinthebay » Tue, Oct 31, 2017, 12:36 PM UTC

Mikushi wrote: post #25

jasode wrote: post #18

The SQLite project seems to have an alternative view: https://www.sqlite.org/testing.html A lot of us would consider SQLite to be high quality and relatively bug-free. The extensive test suite they've built up that exercises each release is a huge reason for it. Of test code quantity , Coplien writes: >If your coders have more lines of unit tests than of code, it probably means one of several things. They may be para…

> Can anyone cite a credible development philosophy that believes testing can replace bad developers or bad process? None. But that's hardly the issue, I too often have seen people championing heavy testing as a way to deliver quality software, because it's the agile way. The problem is not with the philosophies but the way people interpret them or misinterpret them. The sarcastic quote in the article sums my feeling…

Of course, if done well, TDD does both.

Re: Why Most Unit Testing Is Waste [pdf]

#48

Post by wtetzner » Tue, Oct 31, 2017, 12:40 PM UTC

pqwEfkvjs wrote: post #38

"Unit tests are pointless" -- this is often said by developers who suffer Dunning-Kruger syndrome. Except the devs who are actually working on something more exotic that cannot be tested well automatically.

You can have automated integration tests.

Re: Why Most Unit Testing Is Waste [pdf]

#49

Post by wtetzner » Tue, Oct 31, 2017, 12:42 PM UTC

juandazapata wrote: post #20

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

Refactoring code usually means you have to refractor unit tests as well, since they are so closely tied to the structure of the code.

Integration tests, however, should not have to change, since they are typically run against the external interface to the software, which shouldn't change if you're just doing a refactoring.

Re: Why Most Unit Testing Is Waste [pdf]

#50

Post by juandazapata » Tue, Oct 31, 2017, 12:46 PM UTC

wtetzner wrote: post #49

juandazapata wrote: post #20

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

Refactoring code usually means you have to refractor unit tests as well, since they are so closely tied to the structure of the code. Integration tests, however, should not have to change, since they are typically run against the external interface to the software, which shouldn't change if you're just doing a refactoring.

Funny thing. Unit tests force you to think about good code design. Integration tests don't. If you only have integration tests in your system, you'll most likely end up with a big ball of mud. I've seen this so many times in so many real world projects that it hurts.