November 2011 Archives

Blog 4


As what we learned in the class, testing is about the process of executing code and comparing the actual results to expected results. If the actual result fit the expected result, then we say the program is successful; however, if the actual result is different from the expected result, there is some problem with your code. There are many kinds of testing, such as unit testing, component testing, integration testing, regression testing, and system testing. In the class 3081, we did a lab which is about testing with cxxTest, which is a kind of unit testing. Unit testing, however, can be defined as an execution of a complete class, routine, or small program that has been written by a single programmer or team of programmers, which is tested in isolation from the more complete system. So as we can see from the definition, cxxTest is a very basic testing skill. Specifically, what we did in the lab is to write the test for a "ReadInput" file, after loading a cxxTest file provided, we try to use it to test ReadInput function, basically, there involved three tests, the first one ensures that the null pointer is returned if no file name is provided, the second one ensures that the null pointer is returned when the name of a non-existent file is passed and the function attempts to access that file, and the third one ensures that when given proper input referring to an existing, readable, filename, the pointer returned is not null. Finally, we modified the "makefile " to include all the test files we just wrote, and run the program to check the testing results. As I mentioned above, cxxTest is a kind of unit testing, which is basic. Thus, this lab is straightforward, but it is definitely a good way to give a general idea of cxxTest. In addition, it helps we to understand the benefit of testing, which we talked about in the lecture that testing improves your confidence that the code is correct, and avoid collateral damaging in fixing bugs. However, to write a good test, there is a long way to go, as we know from Meyer's first principle, when we write a test, we want to make it fail. But as testing can only find errors, it does not demonstrate their absence. Therefore, we should think about as many situations we can that can make the program fail.

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.