The Software IC (Integrated Circuit) is a metaphor that people like to toss around when discussing reusability and component-based development.The idea is that software components should be combined just as integrated circuit chips are combined. This works only if the components you are using are known to be reliable.
Like our hardware colleagues, we need to build testability into the software from the very beginning, and test each piece thoroughly before trying to wire them together.
Chip-level testing for hardware is roughly equivalent to unit testing in software—testing done on each module, in isolation, to verify its behavior. We can get a better feeling for how a module will react in the big wide world once we have tested it throughly under controlled (even contrived) conditions.
A software unit test is code that exercises a module. Typically, the unit test will establish some kind of artificial environment, then invoke routines in the module being tested. It then checks the results that are returned, either against known values or against the results from previous runs of the same test (regression testing).
Why do we go to all this trouble? Above all, we want to avoid creating a "time bomb"—something that sits around unnoticed and blows up at an awkward moment later in the project.
TIP 48: Design To Test
By making the test code readily accessible, you are providing developers who may use your code with two invaluable resources:
- Examples of how to use all the functionality of your module
- A means to build regression tests to validate any future changes to the code
All software you write will be tested—if not by you and your team, then by the eventual users—so you might as well plan on testing it thoroughly. A little forethought can go a long way toward minimizing maintenance costs and help-desk calls.
TIP 49: Test Your Software, or Your Users Will.
No comments:
Post a Comment