My OperaAssignment 4 -- Testing
Monday, November 7, 2011 8:25:44 PM
Testing is another one of those things that is essential for software development, yet something I only started using in 3081. This semester I am actually taking two classes where the importance of testing is being stressed, 3081W(Project Design and Development) and 5801(Software Engineering I). The reasons to test are not as obvious as it may seem. The obvious reason might be a programmer testing if his code does what it is supposed to do, but the less obvious reasons are to test that the program does not do what it is not supposed to do, or that it meets "business requirements" (a statement that shows up often in Software Engineering especially). Testing for what is not supposed to happen is harder than testing for expected behavior. One has to test for boundary input, invalid input and weird external things like what will happen if the power goes out and system reboots? Those are just some examples of the reasons to do testing. Being that there are so many reasons to test there are different flavors of testing to try and achieve it all. Some of those include unit tests, component tests, integration, regression, system, black and white box testing. For me to cover all of them would be a fruitless endeavor, as I am relatively new to the concept. The little exposure I do have through 3081W, is unit testing and CxxTest as the tool to do it.
So, in more detail, unit testing is testing of specific functions or specific (small) units of code(where unit can be a method or a single class). When unit testing the programmer doesn't just check if the code fulfills a business requirement but also if given inputs the code behaves exactly as expected. Now, this goes for both "good" and "bad" inputs, as it is a good idea to write tests that check expectant failure behavior. This particular area however, is where challenges might arise. As with all tests it is the programmers job to come up with the ranges of "good" and "bad" inputs. That being said, once the unit tests are written they can be augmented with new tests as as the project grows in complexity. This allows a systematic and paced way for the programmer to come up with a good range of possible inputs for the unit tests instead of doing it all at once in a more general test at the end once the large project is over. This incremental approach that unit tests afford really help the programmer in satisfying one of the major requirements of every test -- thoroughness. Another important feature that every test in programming needs to strive for and unit tests can provide is independence. Things like mock objects and fake inputs not only allow to test almost the whole gamut of inputs, but also allow to isolate each and any part of the code to ensure that it works correct.
As with every good idea, someone takes it and makes it better. The way that happened to unit tests is the invention of the many widely available testing frameworks. A testing framework adds more than just the convenience of filling in a few lines of repeated code -- not that insignificant feat in itself as boring "repeatable" parts of coding can often be the cause of programmer error(and thus result in false test results). Testing frameworks also allow the tests to be automated, professional and repeatable --- another 3 important hallmarks of a good test. These three hallmarks I think are especially important in a group project type setting as instead of writing your own tests in one's own unique and quirky way of writing code the testing framework allows for a standardized way for the programmer to write tests. Moreover, having the tests in the framework speeds up the understanding of another programmer who is later trying to augment or simply to understand the tests. Moreover, the framework setting also eases automation allowing someone who knows nothing of the content of the tests to still be able to run them.
The only framework I am familiar with is CxxTest and it pretty much provides all the benefits above. Something that I found a little unsettling at first is using code I don't completely understand. To create tests it is only necessary to include the file that is being tested and use CxxTest's function calls in a CxxTest header file to create the tests, the framework will generate the cpp behind the scenes. As someone who is used to understanding all the in's and out's of what I am turning in this was little unsettling. Another personally challenging thing I found is coming up with good mock input, but once done the set up of TS_ASSERT_EQUALS doesn't require much more thought to implement.
After using CxxTest I think of testing frameworks in context of backing cookies. Backing cookies is good but difficult, so testing frameworks are a form of a ready-bake variety -- you just add some ingredients and you can pop them in the oven!
So, in more detail, unit testing is testing of specific functions or specific (small) units of code(where unit can be a method or a single class). When unit testing the programmer doesn't just check if the code fulfills a business requirement but also if given inputs the code behaves exactly as expected. Now, this goes for both "good" and "bad" inputs, as it is a good idea to write tests that check expectant failure behavior. This particular area however, is where challenges might arise. As with all tests it is the programmers job to come up with the ranges of "good" and "bad" inputs. That being said, once the unit tests are written they can be augmented with new tests as as the project grows in complexity. This allows a systematic and paced way for the programmer to come up with a good range of possible inputs for the unit tests instead of doing it all at once in a more general test at the end once the large project is over. This incremental approach that unit tests afford really help the programmer in satisfying one of the major requirements of every test -- thoroughness. Another important feature that every test in programming needs to strive for and unit tests can provide is independence. Things like mock objects and fake inputs not only allow to test almost the whole gamut of inputs, but also allow to isolate each and any part of the code to ensure that it works correct.
As with every good idea, someone takes it and makes it better. The way that happened to unit tests is the invention of the many widely available testing frameworks. A testing framework adds more than just the convenience of filling in a few lines of repeated code -- not that insignificant feat in itself as boring "repeatable" parts of coding can often be the cause of programmer error(and thus result in false test results). Testing frameworks also allow the tests to be automated, professional and repeatable --- another 3 important hallmarks of a good test. These three hallmarks I think are especially important in a group project type setting as instead of writing your own tests in one's own unique and quirky way of writing code the testing framework allows for a standardized way for the programmer to write tests. Moreover, having the tests in the framework speeds up the understanding of another programmer who is later trying to augment or simply to understand the tests. Moreover, the framework setting also eases automation allowing someone who knows nothing of the content of the tests to still be able to run them.
The only framework I am familiar with is CxxTest and it pretty much provides all the benefits above. Something that I found a little unsettling at first is using code I don't completely understand. To create tests it is only necessary to include the file that is being tested and use CxxTest's function calls in a CxxTest header file to create the tests, the framework will generate the cpp behind the scenes. As someone who is used to understanding all the in's and out's of what I am turning in this was little unsettling. Another personally challenging thing I found is coming up with good mock input, but once done the set up of TS_ASSERT_EQUALS doesn't require much more thought to implement.
After using CxxTest I think of testing frameworks in context of backing cookies. Backing cookies is good but difficult, so testing frameworks are a form of a ready-bake variety -- you just add some ingredients and you can pop them in the oven!
Unregistered user # Monday, November 14, 2011 3:10:58 AM