Why should we bother with unit testing?

| No Comments

When working on a big project, we have to code step by step and the higher level code is based on the low-level code, which means that if the lower level code is not reliable and you fix the bugs in such kind of level, it will still impact code at higher level. Yes, this is very annoying and that's the reason why we should bother using unit testing!

Unit test can give us confidence of what we've written and prove that our code is doing exactly what we think it should do. Some programmers never test their code until most part of the code has been written but by that time, it may be too late, because a project-wide code contains tons of functions and classes and it's hard to locate the positions of the bugs. Sometimes, things can turn to be even worse---we cannot determine what part of the code is working and what's not! I encounter such problems in the first iteration of csci3081w. In iteration 1, we had to add tons of tokenType, such as keywords, punctuations and variables, and created regular expression for every single tokenType. After that, we made a function called scanner, which would match each character in the input file and print out its tokenType to an output file. I didn't test my code until I finished , as a result, you can imagine how many errors I got! Recalling that time, I came to know the significant importance of unit testing.

Anyway, many people still have good excuse for not testing: time consuming--it's hard to set up and to learn testing frameworks, thus devoting valuable time to other tasks is reasonable. Unfortunately, CxxTest,the framework of unit test we are using in our class csci3081w, can counter this excuse. CxxTest has bunch of advantages-doesn't require member template functions,doesn't require any external libraries and doesn't require exception handling.In other words, CxxTest is designed to be as portable as possible.

The first time I use CxxTest was in the lab05 of csci3081. I have to include a header file at the beginning of our ".h file"(for example, "example.h")-- #include < cxxtest /TestSuite .h> (TestSuite is the base class of all tests). Then, I have to declare a class that inherits from TestSuite and in which we should put all the tests that the class is meant to perform. Another important thing I want to mention is that each method inside the class has to begin with "test" and has no return type or any parameters, so that the Python script can see it. There are also a number of assertions that can be used for quality assurance purposes. For example, we can use TS_ASSERT(4 * 4 > 4) to see whether 4*4 is greater than 4 or not and use TS_ASSERT_EQUALS(1+1,2) to see whether the first parameter is equal to the second one. After all these steps are done, the test file will be generated automatically! It's amazing to see that even if you change nothing in the related ".cpp file"(as the example above, this file should be "example.cpp"), all things that should be changed according to the ".h file"(example.h) are already there! My partner and I were both confused when we were doing this lab at the beginning and we even thought about changing the related ".cpp file" using our own source code! After that lab, I was still confused about "Cxxtest" and I asked my best friend Google, who said that after we create a child class of CxxTest::TestSuite, a Python script that actually writes the class that will perform the tests is run. Thus, the script does all the heavy lifting, keeping the developer form wasting hours of time trying to understand the arcane mechanics of the framework.

As far as I'm concerned, this simple idea describes the heart of unit testing: the single most effective technique to better coding!

Leave a comment

About this Entry

This page contains a single entry by Yujng Sun published on November 8, 2011 8:36 PM.

never use source control before? Try it now! was the previous entry in this blog.

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

Categories

Pages

Powered by Movable Type 4.31-en