I'm relatively new to the world of WhiteBox Testing and need help designing a test plan for 1 of the projects that i'm currently working on. At the moment i'm just scouting around looking for testable pieces of code and then writing some unit tests for that. I somehow feel that is by far not the way it should be done. Please could you give me advice as to how best prepare myself for testing this project? Any tools or test plan templates that I could use? THe language being used is C++ if it'll make difference.
+2
A:
At the moment i'm just scouting around looking for testable pieces of code and then writing some unit tests for that. I somehow feel that is by far not the way it should be done.
People say that one of the main benefits of 'test driven development' is that it ecourages you to design your components with testability in mind: it makes your components more testable.
My personal (non-TDD) approach is as follows:
- Understand the functionality required and implemented: both 'a priori' (i.e. by reading/knowing the software functional specification), and by reading the source code to reverse-engineer the functionality
- Implement black box tests for all the implemented/required functionality (see for example 'Should one test internal implementation, or only test public behaviour?').
My testing therefore isn't quite 'white box', except that I reverse-engineer the functionality being tested. I then test that reverse-engineered functionality, and avoid having any useless (and therefore untested) code. I could (but don't often) use a code coverage tool to see how much of the source code is exercised by the black box tests.
ChrisW
2010-05-24 08:20:03
But what happens if the product has already been implemented and all that's left is to test?
Draco
2010-05-24 08:23:10
@Draco If you've implemented it without having tested it or knowing how to test it, then I don't know what happens; but it sounds like it isn't proven a trust-worthy implementation.
ChrisW
2010-05-24 08:37:17
That's the thing. I didn't do any implementation. All I do is the testing (whitebox that is). The developers do test to an extent but i'm there to help as well.
Draco
2010-05-24 08:47:14
@Draco Unless you can change the code to make it more testable, then I think you proceed as I outlined above: know and/or reverse engineer the functionality; test that functionality; use a code coverage tool to verify how much of the source code is being exercised by those tests; write more tests to exercise not-yet-covered/tested code, or complain that the remaining code is unreachable/untestable.
ChrisW
2010-05-24 08:56:49
+2
A:
One of the goals of white-box testing is to cover 100% (or as close as possible) of the code statements. I suggest finding a C++ code coverage tool so that you can see what code your tests execute and what code you have missed. Then design tests so that as much code as possible is tested.
Another suggestion is to look at boundary conditions in if statments, for loops, while loops etc. and test these for any 'gray' areas, false positives and false negatives.
You could also design tests to look at the life cycle of important variables. Test their definition, their usage and their destruction to make sure they are being used correctly :)
There's three ideas to get you started. Good luck
Jacob
2010-05-24 08:22:04
+1
A:
Try "Working Effectively with Legacy Code": http://www.amazon.com/Working-Effectively-Legacy-Michael-Feathers/dp/0131177052
It's relevant since by 'legacy' he means code that has no tests. It's also a rather good book.
Relevant tools are: http://code.google.com/p/googletest/ and http://code.google.com/p/gmock/ There may be other unit test and mock frameworks, but I have familiarity with these and I recommend them highly.
Paul Hankin
2010-05-24 08:51:15
I like these tools - for Java: JUnit, Mockito; for C#: NUnit, Moq. If you're doing white-box testing you may find more value in the stricter mock frameworks - JMock, EasyMock, RhinoMocks.
Lunivore
2010-07-20 12:36:54