Co-Founder, Parasoft Corporation
Adam Kolawa, Parasoft co-founder was truly a pioneer and a champion of software quality and devel... more>>
Unit testing allows you to continuously test parts of the application without the hassles of dealing with the complicated system. Using a technology like Parasoft Tracer, you can create unit test cases that capture the functionality covered in your use cases. To create these tests, you just exercise your use cases while Tracer is enabled. As the use case is executed, Tracer monitors all the objects that are created, all the data that comes in and goes out, and then it creates you a unit test that represents this operation-and even sets up the proper initial conditions.
You can then take this unit test case and execute it on a separate machine, away from the original system. This means that you can use a single machine-even a standard developer desktop-to reproduce the behavior of a complicated system during your verification procedure. Add all of these tests to your regression test suite, run it continuously, and youll immediately be alerted if this functionality that you captured is impacted by your code modifications.
Essentially, this helps you address the complexity of todays systems in two ways:
1. It relieves you from having to perform all the time-consuming and tedious work required to set up realistic test conditions.
2. It gives you a test case that you can run apart from the system - a test case you can run continuously and fully automatically.
This type of unit testing is not early testing at all. Its a completely different flavor of unit testing, and I think its even more valuable than early testing. But, theres still a time and place for early testing.
A Place for "Early Testing" Unit Testing
Say you have a brand new application that youre writing from scratch. As you implement each chunk of functionality, why not write a unit test that captures how this functionality is supposed to work? At this point, youre familiar with the requirement being implemented and you know all about how the code works... so this is the best possible time to set up the conditions properly and write a test that really verifies the requirement.
While youre at it, why not also mark the test case to indicate what requirement it implements? This way, it can always be correlated to the appropriate requirement. If the test fails, youll know what requirement was affected. And from the other end, you can go from a requirement and back-trace to all associated tests and their status. This lays the foundation for requirements traceability.
When youre done writing each test, add it to the regression test suite and execute it continuously-just like you would do with the other type of unit tests.
You could write these tests right after the code is implemented. Or you could write them before you even start working on code (in the spirit of TDD).
Experts on QA