From concept to working software in 10 minutes

So if testing is a good thing, why not test all the time? In fact, why not start out with testing?

If you have a large stretched-out project with a fair bump of testing on the end, we’ve seen that often the testing phase will be pressured because of the deadline. What is even worse is that the valuable feedback from the testing phase will have no way to be incorporated into the design and code of your project.

We’ve seen that to accommodate learning in a process we have to make it iterative and build in practices that facilitate and encourage learning.

Test:
Think about your goal, what it is you are trying to achieve. Keep your large goal in mind but as small goals are easier to achieve then large goals, focus on a tiny subset of the problem. Choose the tiniest subset that will bring you the closest to the great goal when implemented.
Now figure out what it would look like when your tiny subset if finished. For instance; a customer enters a valid email address. Think of some test cases for it.
• User enters a valid email address -> test passes.
• User enters an invalid email address -> test fails.

Requirements:
Quickly think of the requirements that you need to implement this subset of functionality. You need to know what makes a valid email address and you need to have an email address to validate.

Design:
As you have thought briefly about your test case you are now ready to do the design. You do the design as you type up the test code:

    $objEmailValidator = new emailValidator;
    $validEmailAddress = ‘marko@brains4all.com’;
    $invalidEmailAddress = ‘http://www.brains4all.com’;
    assertTrue($objEmailValidator->validate($validEmailAddress);
    assertFalse($objEmailValidator->validate($invalidEmailAddress);

Apparently we are going to need some object to house our validation routines, it has a method called “validate” that you pass a single string value: the email address to check. In this case it passes in our valid email address.

Code:
Now write just enough code to pass the test. Nothing more. Don't create stuff you might be needing later. Just the code to pass the tests:

    Class emailValidator {
        function validate ($emailToCheck) {
            if ($email == “marko@brains4all.com”) {
                return true;
            } else {
                return false;
            }
        }
    }

Run the tests, if and not until all the tests pass you can check it into the versioning system, from where it can be released as working software.

That’s it; you’ve written your first test in an iterative manner and released your first working code for your customer to review and to bestow feedback on.

But wait!
How can you be serious? The code above only checks to see if it is your email address that was entered. What if I entered my own, the test would surly fail but my email address is definitely valid as well.

Well, let’s try it and add another test. Remember this is an iterative process.

    $objEmailValidator = new emailValidator;
    $myValidEmailAddress = ‘marko@brains4all.com’;
    $invalidEmailAddress = ‘http://www.brains4all.com’;
    $yourValidEmailAddress = ‘blogreader@bloglines.com’;
    assertTrue($objEmailValidator->validate($myValidEmailAddress);
    assertTrue($objEmailValidator->validate($yourValidEmailAddress);
    assertFalse($objEmailValidator->validate($invalidEmailAddress);

If we run the tests, the new test fails miserably. You’re right. You have to change the code to make it pass:

    Class emailValidator {
        function validate ($emailToCheck) {
            if (preg_match("/^[a-z0-9_.-]+@[-.a-z0-9]+\.[a-z]{2,6}$/i", $emailToCheck) == 1) {
                return true;
            } else {
                return false;
            }
        }
    }

If changed the code to have a simple regular expression match. Let’s run the tests again. Hey, the tests pass; quickly check in your code to be delivered to the customer! Can you think of a test to break the code?

Repeat until you can’t think of any test cases, or your test cases stop being sensible or relevant. Move on to the next tiny subset of functionality you need to implement. Be sure to talk to the customer about the software you’ve made. Find out how he likes it and to see if any improvements can be made. Does your code address what the user needs?

Trackback Pings

TrackBack URL for this entry:
http://people.brains4all.com/weblog/mt-tb.cgi/15

Comments

Post a comment