Unit Tests, Why Use Them?

I'm here talking about Unit Tests, and why companies use them. Specifically, I want to talk about this paper.

Unit tests are basically tests that plug something into a program and expect a certain output. If they do not receive that specific output, then the test is "failed." These can be useful because people who didn't necessarily write the program can test the program by knowing what outputs should be. This can give useful information to the programmer if something has broken, or is not working correctly. A suite of unit tests should provide information to the programmer whether the program is running correctly or not.

What James Coplien is arguing in this article is that, in his words, "The cure is worse than the disease," meaning of course that the time spent writing unit tests is greater than time spent debugging code. He goes into a multitude of reasons why, including unit tests being over-required, and too many tests provides less information than the correct tests. I think he makes valid points, and what I like about this article is that he talks about the problems, but tries not to generalize unit tests being "bad" or "useless." He instead talks about how the original vision for them has become outdated as programming goes to new places, and requirements for unit tests are ridiculous in the workplace to the point where sometimes the tests are more complicated than the original program.

I have always thought that unit tests were not all that useful, but I assumed that this was because I was working on projects alone, and when you have a plethora of coders working on the same program, things could get complicated to test without a unit test. I still think that is the case. The problem with the solutions boasted in this article is that they rely too heavily on the competence and similar thought of everyone on the team. Not everyone will be able to write their programs to be testable, and generally, that will just be how it is. It is simpler to have unit tests, which are dedicated to testing the program, than have everyone be able to test their own code, and test within the program itself. This solution is certainly better if it is only a team of 4 to 5, but how could you expect a team of 80 programmers to be able to test together like that? I think it's unrealistic.

Overall, I think the writer is correct, unit tests are used incorrectly and inefficiently a lot of the time. But that is simply the way it is with software engineering, there is inefficiency when business and computer science interact. Hopefully, we will get to a point some day where enough people understand computer science in similar fashions where these problems won't crop up, but it seems unlikely.