]
]Ensuring adequate testing is a critical success factor for your project. Often promising teams produce inferior products due to inadequate testing.
Test Driven Development (TDD) advocates writing test cases before writing the code. While TDD has its share of detractors, it is considered an exciting way to develop code, and its benefits outweigh the drawbacks (if any). It is certainly suitable for student projects. It might feel a bit counter-intuitive at first, but it feels quite natural once you got used to it.
When the presence of a bug is discovered (i.e., we know there's a bug in the code, but we don't know where exactly it is hiding), it usually means one thing: you have not done enough testing! There is at least one test case you should have written but didn't.
If you tell the weakest member of the team "You do the testing, we'll take care of the rest of the stuff", that is a recipe for disaster. Every one must unit-test their own code, and do a share of other types of testing as well (i.e., integration/system testing). But you can have one person in charge of testing (the so-called testing guru).
Supervisors often get the question "Isn't it enough just to do the system testing - If the whole works, then parts must surely be working, right?"
Another frequent question from students: "how many test cases should we write?"; Answer: "As many as you want"
If you are confident that your system works perfectly and does not require any testing, there is no need to write a single test cases. Coming back to the reality, it is not unusual to have more testing code (i.e., test cases) than functional code.
On the other hand, the number of test cases by itself does not guarantee a good product. It is the quality of the test cases that matters.
Decide what testing policies/guidelines you are going to apply for your project (e.g., how to name test classes, the level of testing expected from each member, etc.). This can be done by the testing guru.
A test case has an expected output. A proper test case should have its expected output calculated manually, or by some means other than using the system itself to do it. But this is hard work. What if you use the system being tested to generate the expected output? Those test cases - let us call them unverified test cases - are not as useful as proper test cases - they pass trivially, because the expected output is exactly the same as the actual output (duh!). However, they are not entirely useless either. Keep running them after each refactoring you do to the code. If a certain refactoring broke one of those unverified test cases, you know straightaway that the behavior of the system changed when you did not intend it to! That's how you can still make use of unverified test cases to keep the behavior of the system unchanged. But make sure that you have plenty of proper (verified) test cases as well.
Use exceptions where appropriate. Use assertions liberally. They are not the same (find out the difference), and the two are not interchangeable.
It has been claimed that MSOffice has about 250,000 LOC of assertions (about 1%). Various past studies have shown up to 6% of code as assertions in various software. Microsoft found that code with assertions has a lesser defect density.
Being the author of the code, you tend to treat it gingerly, and test it only using test cases that you (subconsciously) know to work. Instead, good testing require you to try to break the code by doing all sorts of nasty things to it, not try to prove that it works. The latter is impossible in any case.
If you experiment with your code (to find a bug, or to find the best way to fix a bug), use your SCM tool to rollback the experimental modifications that you did (but no longer required).
Cross-testing means you let someone else in your team test a module you developed. This does not mean you don't test it yourself; cross-testing is done in addition to your own testing. Cross-testing is additional work, delays the project, and is against the spirit of "being responsible for the quality of your own work". Perhaps you should use it only when there is a question of "low quality work" by a team member. Any bug found during cross-testing should go on the record, and should be counted against the author of the code.
Do not assume that others will use your code the way it is supposed to be used; actively prevent others from misusing it.
Do not assume a piece of code to be perfect just because you wrote it yourself (there is no such thing as perfect code). Test it to the maximum using unit tests.
This is also called defensive programming. Exceptions and Assertions can help you a lot in defensive programming.
Submit your bank of test cases as part of the deliverable. Be sure that you can run the whole lot of them at a moments notice. A quick test one can use to check the quality of the test cases is to do a slight modification to the code (i.e., insert a bug) and re-run the test cases. If the test cases have good coverage, at least one test case should fail, and it should be easy to locate the inserted bug based on the test results.
Unless explicitly prohibited by your instructor, add a couple of sample test cases to your report. Be sure to pick those that show your commitment to each type of testing. It is best to showcase those interesting and challenging test cases you managed to conquer – not those obvious and trivial cases. You can use a format similar to the following:
Test Purpose: explain what you intend to test in this test case
Required Test Inputs: what input must be fed to this test case
Expected Test Results: specify the results expected when you run this test case
Any Other Requirements: describe any other requirements for running this test case; for example, to run a test case for a program module in isolation from the rest of the system, you may need to implement stubs/drivers.
Sample Code: to illustrate how you implemented the test case
Comments: Why do you think this case is noteworthy?
Any suggestions to improve this book? Any tips you would like to add? Any aspect of your project not covered by the book? Anything in the book that you don't agree with? Noticed any errors/omissions? Please use the link below to provide feedback, or send an email to damith[at]comp.nus.edu.sg
 |
Sharing this book helps too! |
---| This page is a part of the online book Tips to Succeed in Software Engineering Student Projects V1.8, 3rd Sept 2008, Copyrights: Damith C. Rajapakse |---