Follow Techotopia on Twitter

On-line Guides
All Guides
eBook Store
iOS / Android
Linux for Beginners
Office Productivity
Linux Installation
Linux Security
Linux Utilities
Linux Virtualization
Linux Kernel
System/Network Admin
Scripting Languages
Development Tools
Web Development
GUI Toolkits/Desktop
Mail Systems
Eclipse Documentation

How To Guides
General System Admin
Linux Security
Linux Filesystems
Web Servers
Graphics & Desktop
PC Hardware
Problem Solutions
Privacy Policy




Thinking in C++ Vol 2 - Practical Programming
Prev Home Next

A simple unit test framework

Writing software is all about meeting requirements.[20] Creating these requirements is difficult, and they can change from day to day; you might discover at a weekly project meeting that what you just spent the week doing is not exactly what the users really want.

People cannot articulate software requirements without sampling an evolving, working system. It s much better to specify a little, design a little, code a little, and test a little. Then, after evaluating the outcome, do it all over again. The ability to develop in such an iterative fashion is one of the great advances of the object-oriented approach, but it requires nimble programmers who can craft resilient code. Change is hard.

Another impetus for change comes from you, the programmer. The craftsperson in you wants to continually improve the design of your code. What maintenance programmer hasn t cursed the aging, flagship company product as a convoluted, unmodifiable patchwork of spaghetti? Management s reluctance to let you tamper with a functioning system robs code of the resilience it needs to endure. If it s not broken, don t fix it eventually gives way to, We can t fix it rewrite it. Change is necessary.

Fortunately, our industry is growing accustomed to the discipline of refactoring, the art of internally restructuring code to improve its design, without changing its behavior.[21] Such improvements include extracting a new function from another, or inversely, combining member functions; replacing a member function with an object; parameterizing a member function or class; and replacing conditionals with polymorphism. Refactoring helps code evolve.

Whether the force for change comes from users or programmers, changes today may break what worked yesterday. We need a way to build code that withstands change and improves over time.

Extreme Programming (XP)[22] is only one of many practices that support a quick-on-your-feet motif. In this section we explore what we think is the key to making flexible, incremental development succeed: an easy-to-use automated unit test framework. (Note that testers, software professionals who test others code for a living, are still indispensable. Here, we are merely describing a way to help developers write better code.)

Developers write unit tests to gain the confidence to say the two most important things that any developer can say:

1.      I understand the requirements.

2.      My code meets those requirements (to the best of my knowledge).

There is no better way to ensure that you know what the code you re about to write should do than to write the unit tests first. This simple exercise helps focus the mind on the task ahead and will likely lead to working code faster than just jumping into coding. Or, to express it in XP terms:

Testing + programming is faster than just programming.

Writing tests first also guards you against boundary conditions that might break your code, so your code is more robust.

When your code passes all your tests, you know that if the system isn t working, your code is probably not the problem. The statement All my tests pass is a powerful argument.

Thinking in C++ Vol 2 - Practical Programming
Prev Home Next

   Reproduced courtesy of Bruce Eckel, MindView, Inc. Design by Interspire