ALM Best Practices

Unit Testing: Is it Nearing Extinction?

By Adam Kolawa, Parasoft CEO and Co-Founder

Some people claim that unit testing is going the way of the dinosaur, but I think that unit testing is more valuable now than ever. However, I think we need a different flavor of unit testing than the one everyone always focuses on, which is early testing. Let me explain.

A New Breed of Unit Testing

The distributed & heterogeneous systems we’re building today (cloud, SOA, RIA, etc.) are growing in size and complexity—plus developers are being asked to evolve them faster than ever before. We typically have a good idea of what functionality we need to test because the use cases are usually well-defined in requirements. However, it’s difficult to test use cases that span across these complicated systems—they pass through system components that are difficult to access & test, dev/test environments are difficult to establish and maintain, each test requires considerable setup, and so on. It might be feasible to test each use case once, but you really need to test all your use cases daily so that you’re immediately alerted in case your constant modifications end up breaking them.

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 you’ll immediately be alerted if this functionality that you captured is impacted by your code modifications.

Essentially, this helps you address the complexity of today’s 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. It’s a completely different flavor of unit testing, and I think it’s even more valuable than early testing. But, there’s still a time and place for early testing.

A Place for "Early Testing" Unit Testing

Say you have a brand new application that you’re 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, you’re 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 you’re 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, you’ll know what requirement was affected. And from the other end, you can go from a requirement and backtrace to all associated tests and their status. This lays the foundation for requirements traceability.

When you’re 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.