Just as the lawn must be mowed and walls must be painted, software engineering requires the developers among us to test our software. But development testing doesn’t have to be akin to watching grass grow or paint dry; it can be an integral part of the development process, and in doing so, become quite engaging. What if one of your tests reveals a critical bug? What if another helps to identify code that is a candidate for optimization, and the result of that yields a performance improvement that is one or two orders of magnitude better? When that happens, development testing becomes more of a puzzle than a chore.
The only developer who doesn’t appreciate the diligence of his or her Quality Assurance (QA) staff is one who has never made a mistake. QA ninjas, such as the ones at MerlinOne, are quite clever at concocting new ways to attempt to break our products. However, QA is just the final line of defense as fledgling software leaves its development nest and makes its way toward our customers. The goal of every developer is to deliver to QA code that is already thoroughly tested.
Unit Testing is a process by which small, well-defined test cases are created for each component in a program. Even a relatively small program might have hundreds of associated unit tests when the external components upon which it is built are taken into account. These tests guard against cases where seemingly benign changes to a program’s implementation might have negative side effects in terms of accuracy and/or performance. Because each newly added component has an accompanying unit test, the test suite builds over time to become very comprehensive.
Once a developer gets bitten by the Unit Testing bug, he or she will probably discover Test Driven Development (TDD), which is a process where unit tests are written before the code being tested. While that might seem like a variation of the age old question “which came first, the chicken or the egg?”, it can be compelling when considered carefully. Traditionally, when creating a software component, developers must consider functional requirements in order to finalize its design. The design is then implemented, and that implementation is ultimately tested. With TDD, the tests for the component are created during the design phase, and the implementation is built such that all tests pass. Because tests tend to be more directly tied to functional requirements, TDD encourages developers to focus on them more during the combined design/test phase. Like Unit Testing, a complete software system built with TDD will also result in a comprehensive test suite.
As modern software systems grow in scale and complexity, it is hard not to wonder how such efforts are sustainable. More likely than not, there are hundreds of small, modular tests making that possible.
Michael Ellis
Senior Software Engineer
Email: mellis@MerlinOne.com
Phone: 617.328.6645
If you would like to learn more about MerlinOne’s products and services please…
