The Code-Driven Approach to Automated Testing

Automated testing saves software developers the trouble of looking for bugs manually. Think of it as a bug zapper that does a better job of killing bugs than a fly swatter. However, the zapper is only one in a set of other common bug control solutions. The same can be said of automated testing with three well-known approaches.

First is the code-driven test (CDT). As far as the workflow goes, CDT is a "cycle of cycles" where the tester undertakes several processes and backtracks if the test fails or passes in one of the processes. The cycle can only be broken if the development stops. Here's a more convenient way to view CDT.

1. Add new test
2. Execute test
   1. PASS: Repeat Step 1
   2. FAIL: Proceed to Step 3
3. Change code
4. Execute test
   1. PASS: Repeat Step 1
   2. FAIL: Repeat Step 3

Experts say the first CDT cycle should fail to find out the type of code that needs to be written. If something in the program doesn't fail the first time, the entire test would be rendered meaningless. Failure is normal in automated testing; it means the program has room to grow. You'll find the need for automated testing in the future when you want to add more functions.