Unit testing: Why it is a bad idea.

2    23 Feb 2017 22:33 by u/roznak

I understand unit testing, it does have its uses. However recently every developers was asked how many unit tests they had for their project. Somehow the quality of the code was measured in number unit tests.

If you are a seasoned developer you know that this is quackery and then number of unit tests has no way to measure if your code is good or bad. I seen numerous of failing applications in production that have all the green LED status.

The number of unit tests actually reflects the waste of resources you put into pointless unit test code and unit test data generation code that you could have used for developing good code in the first place.

I see unit tests that have more complex code to generated the needed data and remove them again to clear the database that it has functional code. These unit tests actually alters the real production field so when you ship the product you end up surprised since the unit tests does not reflect reality.

Now why is there the rise of need of unit tests? Because of the obvious reason where IoC makes you code unreadable and the only way to make sure if you messed up if by creating a unit test. This IoC needs enormous pointless additional source code lines that have absolutely no function except to make the real source more complex.

They call it "reusable" but all they are doing is create one giant pile of sitting objects. Elegant design has turned into Franken-design. Where your code fails to operate reliable at the customers site and no one has any clue why.

Make code development great again! Bring back good software!

3 comments

1

Unit testing is good for libraries and computational components, but can't replace integration and smoke tests for applications.

1

When creating a prototype of something, I agree with you; unit tests are often overkill.

However, as soon as your program becomes more complex, I find that unit tests are necessary. Otherwise, it's too easy to introduce regressions. After all, a programmer can't think of all possible corner cases at the same time.

0

Unit testing is important because it describes how a function or class should work. Outside participants to the project could first look at the test, and from observability perspective determine what it's supposed to do.

Unless you can go through the rigorous exercise of proving out that your code works with linear logic, it's hard for someone to claim that something will work out of box when they ship it.

Test coverage as a number means nothing, that I agree, and often programmers don't know the difference between unit tests and integration tests. Often unit tests are not valuable when the developer writes something that isn't really testing the functionality from input output perspective. Side effects are hard to test when dependencies increase for a given unit.

LOC isn't the objective for writing code. Source isn't made any more complex by adding unit tests - if it is, then the programmer is doing something wrong by injecting test specific stuff into prod code.

Reusability isn't the principal claim that unit test advocates are making. The claim is that extensive tests reduce two things:

  1. Incorrect assumptions about the code itself
  2. Regression errors due to new feature deployment

Different point being made here is about what constitutes elegance, and that is outside of the scope of debate about unit tests.