November 2011 Archives

Why Unit Testing?

| 7 Comments

In large and complex projects, if you do not check your changes during the development but keep coding, it is hard to debug after you finish coding. Since in such a case it is not easy to find where the bugs are, and even worse, more bugs will be aroused during the process of debugging. Fortunately, there is a general way in software development to avoid such a terrible situation. Programmers usually use unit testing to test a small, specific area of functionality of the code. They do this in order to see if it works as it is supposed to do. Consequently, unit testing gives us confidence to move forward, because we know that what we have satisfy our requirements.

Some people may complain, we have already taken so much time coding, why do we need to add another task to ourselves like unit testing to increase our work load? However, instead of adding burden, unit testing, as mentioned above, not only proves the correctness of your previous work, but also lightens your work load by reducing the time of debugging. You actually have more vacations! Imagine that you do not need to spend every night coding to 2 am, but test your work and then have a good rest. Imagine that you do not need to sit in front of your computer debugging all the time, but can go on a date with your girlfriend. Unit testing is such a time-saving task compared to debugging, especially when there is a lot of excellent test framework such as cxxTest that we use to test our C++ code in 3081.

When I first used cxxTest, I erroneously replaced our source code by the automatic generated file. I did not notice that the test file was generated automatically, though the comments in the file said it was. When running the test cases, our codes did not work for sure. Furthermore, I thought there was something wrong in the file and tried to find some bugs. I was totally wrong! There was another error confusing me for a long time during that day that I wanted to share with the beginners. When I used the TS_ASSERT_EQUALS of cxxTest, our first parameter was a function of type char**. I then passed the NULL as the second parameter. When I tried to test my assertion, the prompt window showed a bunch of mass error messages that I did not understand and had not encountered before. I obviously forgot what they were as well. I then Googled the error and looked at the code for a long time. I finally realized that they had different types, but might have the same value. Since NULL is a macro definition which is actually the integer 0, but the TS_ASSERT_EQUALS requires the two parameters at the same time, just like the std::min and std::max functions, it is not like the TS_ASSERT which may involve implicitly converting the type of parameters. Consequently, I passed a constant nil that is defined as const char* nil = NULL to the TS_ASSERT_EQUALS and it finally worked.

However, many skills are easy to make mistakes with for beginners. Once we get started, we will find that they are very convenient. I am also a beginner of cxxTest. I now just know it is easy to test our assertion. Hopefully I can master it soon.

About this Archive

This page is an archive of entries from November 2011 listed from newest to oldest.

October 2011 is the previous archive.

Find recent content on the main index or look in the archives to find all content.

Pages

Powered by Movable Type 4.31-en