Why Unit Testing?


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.


I like the example you provided regarding the issue with TS_ASSERT_EQUALS. I also ran into that problem and I'm sure many others ran into it as well. I agree with you that cxxTest will be an important time saver to our projects and others.

-Tom Hoang

I met the same problem as you and it it wired when I first saw it. What's more, I do agree with you that we need to study further and practice more on CxxTest.

Fan Yang

Yup, CxxTest is still a big knowledge to learn, maybe through Iteration 3~? and keep testing our code will let us master in CxxTest.

I run into the same problems when I first use the CxxTest. I believe we still need some more practise on the test. It will help not only in this course but also in the future life.

Letao Jiang

Yes, it is kind of struggling at the beginning. But as time goes and we get to used to it, it is quite useful.

Yanjie Zhang

Sorry i pasted sth wrong to it.......

I agree that testing frameworks can be useful for larger programming projects but I thought that the amount of work required in this situation outweighed the benefits. So far we have dealt only with a small set of units to test and the required time for test development in our group nearly exceeded the amount of time that went into actual development.

Leave a comment

About this Entry

This page contains a single entry by xuxxx728 published on November 8, 2011 1:10 AM.

My experience of SVN was the previous entry in this blog.

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


Powered by Movable Type 4.31-en