Gregory M. Kapfhammer

Associate Professor of Computer Science

http://www.cs.allegheny.edu/~gkapfham/

  
View  Edit  Uploads  History  Top  Changes  Search

Learn to Love Unit Testing

  • The authors of this article contend that software developers should learn to love writing software in a test-first manner. What are some of the benefits that might be associated with performing test-first implementation?

There are many benefits that are discussed within this article. First of all it is mentioned that it gives the developer a place to start. By start with a simple test case the developer has a place to start coding, rather than with just a blank editor. By writing tests before code, the programmer is always making progress; writing code to fix a failed test case. By programming in this manner the code writer also catches errors as you go, rather than trying to figure out what went wrong in a large system. Probably the strongest argument made in favor of Unit testing is that by writing test cases, then producing code to pass this test, the developer knows that the code he just produced hasn't injected problems in the existing code.
Brandon Taylor
Writing your unit tests before writing code enforces clear objectives. The programmer will realize precisely how the code must behave when he writes his tests, and will carry that knowledge into coding.

It's also beneficial to the programmer because the large task will be broken up into smaller, more manageable chunks. It is easier to tackle a few smaller problems than a single large problem. bps

In this article, the author stats several benifits to unit testing. First it helps you get past the first step, starting. When you set up your packages and then begin to outline your test it helps to get going on the code. If you set up your first test to test something, then it gets you going on the code that you have to write so your test passes. Testing also helps you gain confidence in your coding. When you make test and you see the "green bar" when you run your test, it puts confidence into your coding.
John Pacino
  • In this article, the authors concede that there might be some situations in which unit testing is not applicable. Discuss some of the situations that they list and provide some other situations as well. What are some of the characteristics of applications that appear to be "untestable", "less testable", or "harder to test"?

The author goes through a series of reasons why developers say testing is not for them. The only excuse he gives credit to is that some code can not be tested. Some examples that the author gives are where your code interacts with an outside system, or in systems that are constantly changing such as stock tickers. Some other situations where testing would not be possible or very difficult would be in real time systems. Testing under this scenario is near impossible, because results that could be expected at the time the test is written will not be the case at run time. Another situation that testing would be hard is in the interaction of a database. In general it is hard to test software that has fluctuating results, or the results are dependant on outside systems. Your system could work fine, however your test could still fail because the outside system is faulty.
Brandon Taylor
The authors claim that testing systems outside of their control is not possible: ie. testing a GUI, or testing a system that needs to interact with the code. The way to test your code as thoroughly as possible is to leave the majority of the functionality inside the system that can be tested: write a simple GUI and put the real functionality in testable modules. They also suggested simulating the processing from external systems; possibly something like Mock Objects. bps

Some situations that the out claims that can not be tested are ones that are interfacing with hardware or an external system outside thier control. Some of these situations may not give the same result everytime making it difficault to test. The author says one way to overcome these situations is to simulate the external systems, such as what NASA does with space crafts and technologies.
John Pacino


  • The authors list several "excuses" that developers provide when they state that they do not want to perform unit testing. What are some of these excuses? Can you find any holes in the rebuttals that the authors provide for these excuses?

There are many excuses that the author provides for developers not testing:
  1. Writing tests takes too much time.
  2. Tests break the flow.
  3. Testing is too complicated.
  4. Testing is unnecessary
  5. I have a gazillion lines of legacy code.
  6. Some software can't be tested.
Writing tests does take a lot of time, and it's difficult to determine which functionality should have a unit test. For example, it's overkill to write tests for simple methods such as getters and setters; but where do you draw the line?

Writing tests may also break the flow – if the authors' solution does not work, I think priority must go to writing the tests: it's too easy to say "Well, this functionality is already working, I don't need a test."

The authors' responses to the "unnecessary" and "complicated" arguments were exactly right. However, I disagree with their response to the "legacy code" case. Part of the strength of unit testing is the confidence that changes to your code do not affect other areas of the code. If you write tests for only part of the system, you don't get this confidence. All or nothing, I say. That might not be pragmatic, as the authors claim their solution is, but it is complete.

Again, some code cannot be tested, but if the authors' advice is taken, the developer can be reasonably sure that their code is correct. bps

Some excused programmers give for a reasond not to test are:
  • Tests breaks the flow
  • Testing is unnecessary
  • Testing is too complicated
  • Writing test takes to long

Writing test takes to long, here the author says that it will save the programmer time if they test, but sometimes the test can be longer than the code itself. If there are certain parts in the code that are working, you may not need to spend the time "test a little, code a little" because you know that the code is fairly easy and going to work

Testing is unnecessary, if you are on a time table or a deadline, you may not have enought time to make all the test that should be made for the code. It may be easier to save your time for the end and fix all the bugs after you are done. Fixing the larger bugs first then getting down to the smaller bugs and if deadline comes, you may have what microsoft calls "good enough" software.
John Pacino

Link to this Page