BalaBit Blog

“When you have a problem to solve, use regular expressions! Now you have two problems!”

Regular expressions are very useful tools in the inventory of a programmer: they can be used to validate a string according to a given format, or to find and extract parts of a string, or even to change substrings matching a given pattern. But when you write some hellish tricky regular expression, do you stop for a moment to think about the spaghetty of while loops and switch-case statements that your regexp will translate to? I mean just a few characters of regexp may specify a state machine that would take tens or maybe hundreds of lines of loops and conditionals to implement. All that amount of code gets executed whenever you use your regexp, so you would need a big amount of testcases to cover that state machine if you happen to practise Test-driven development (TDD). In this experiment I’m going to blindly apply the three well-known steps of TDD to create a regular expression for a given task, and see how far I can get and how much time it takes.

These three steps of the TDD cycle are:

1. Write a failing unit test (compilation errors are considered a failure).
2. Write just enough production code and not a single line more to pass the failing test.
3. Cleanup the mess created during the first two steps.

Or in short:

1. Red
2. Green
3. Refactor

My kata

My kata for this experiment will be validating a simple time specification, that contains two digits of hour and minute parts separated by a colon and either AM or PM in case of 12 hour notation. The rules are going to be:

• Valid time specifications should always contain a two digit number (with a leading zero if necessary) describing the hour of the day followed by a colon followed by a two digit number (with a leading zero as well) to describe the minute of the hour.
• The HH:MM part may be followed by a single space followed by two alphabetic characters, either AM or PM. In this case the time specification is considered to be in 12 hour format, thus the hour part should not be more than 12.
• When there is no AM or PM at the end of the string, the time specification is considered to be 24 hour format, in which case the hour part should be between 00-23 (inclusive).
• In any case, the minute part must be between 00-59 (inclusive).

The job is to decide if a string matches all the above rules or not.

There are a million possible implementations, but for now, let’s evolve this one by applying the TDD development cycle to meet the requirements. The language is going to be PHP, the testing framework will be PHPUnit, and the implementation will rely on PHP’s preg_match() function. First, let’s start from very small, trivial steps. Going forward, we may speed things up, just like in Kent Beck’s wonderful book.

The first testcase

In TDD, tests come first, so let’s create a simple testcase:

<?php

require_once 'TimeValidator.php';

class TimeValidatorTest extends PHPUnit_Framework_TestCase
{
    public function testTimeValidatorCanBeCreated()
    {
        new TimeValidator();
    }
}

?>

This will fail badly, obviously, but let’s run it, just to be sure!

PHPUnit 3.5.15 by Sebastian Bergmann.

PHP Fatal error:  Class 'TimeValidator' not found in /home/athos/projects/TimeValidator/TimeValidatorTest.php on line 7
PHP Stack trace:
PHP   1. {main}() /usr/bin/phpunit:0
PHP   2. PHPUnit_TextUI_Command::main() /usr/bin/phpunit:49
PHP   3. PHPUnit_TextUI_Command->run() /usr/share/php/PHPUnit/TextUI/Command.php:129
PHP   4. PHPUnit_TextUI_TestRunner->doRun() /usr/share/php/PHPUnit/TextUI/Command.php:188
PHP   5. PHPUnit_Framework_TestSuite->run() /usr/share/php/PHPUnit/TextUI/TestRunner.php:305
PHP   6. PHPUnit_Framework_TestSuite->runTest() /usr/share/php/PHPUnit/Framework/TestSuite.php:733
PHP   7. PHPUnit_Framework_TestCase->run() /usr/share/php/PHPUnit/Framework/TestSuite.php:757
PHP   8. PHPUnit_Framework_TestResult->run() /usr/share/php/PHPUnit/Framework/TestCase.php:576
PHP   9. PHPUnit_Framework_TestCase->runBare() /usr/share/php/PHPUnit/Framework/TestResult.php:666
PHP  10. PHPUnit_Framework_TestCase->runTest() /usr/share/php/PHPUnit/Framework/TestCase.php:628
PHP  11. ReflectionMethod->invokeArgs() /usr/share/php/PHPUnit/Framework/TestCase.php:738
PHP  12. TimeValidatorTest->testTimeValidatorCanBeCreated() /home/athos/projects/TimeValidator/TimeValidatorTest.php:0

Yeah, we are in Red! Now we can write a tiny bit of production code in the hope we will get into the Green phase:

<?php

class TimeValidator
{
}

?>

And now the test passes, we’re in Green.

Is there anything to refactor here? We have 0 ELoC, so let’s move on. I’m going to ignore Tell, don’t ask! for this kata, so I’m going to call the one and only public method of my TimeValidator class isValid(). Maybe later I’ll come up with a cleaner name for both the class and the method, but it will do for now. But before we could write any more lines of production code, we need a failing testcase first. So let’s do some actual work in the testcase:

public function testTimeValidatorCanBeCreated()
{
    $validator = new TimeValidator();
    $this->assertTrue($validator->isValid('10:42'));
}

There’s no such method, so this will fail. Let’s implement the method with an empty body in TimeValidator.php:

public function isValid($time_specification)
{
}

Again, the test fails because NULL does not equal to true. We’re still in Red, so we can write some more production code, because the lines we have written so far are not enough to get us into Green. What is the simplest algorithm that will make our failing testcase pass if implemented in the production code? Yes, it’s a big facepalm:

public function isValid($time_specification)
{
    return true;
}

And now we’re in Green. Let’s do some refactoring!

The name of our testcase lies: it says it checks the construction of our newly defined class, but actually the return value of a function is being checked. So let’s rename the testcase as a refactoring:

public function test24HourFormatIsAccepted()
{
    $validator = new TimeValidator();
    $this->assertTrue($validator->isValid('10:42'));
}

I decided to consider 10:42 to be in 24 hour format, because that is the simplier one.

Is there any more opportunity to refactor? Though our validator is very useless at the moment, we don’t have any tests to enforce us to implement some real functionality in that method, so we’re not allowed to change that code to something more complex. We were required to write just enough production code to pass the failing test, and we’ve done exactly that and not a single line more.

Now what about creating a failing testcase to let us move forward?

A negative test

After a few seconds of thinking, I decided to test if our method does care about colons. Any kinds of time specifications mentioned in the requirements must contain a colon character, so it gives us a fairly simple testcase:

public function testTimeSpecificationMustContainOneColon()
{
    $validator = new TimeValidator();
    $this->assertFalse($validator->isValid('1042'));
}

Sadly Hooray, a failure! We’re back in Red, let’s write some more production code! Sadly a fairly simple change to our isValid() can make this test pass:

public function isValid($time_specification)
{
    return $time_specification != '1042';
}

Back in Green, but far from any meaningful code. At least we can refactor, luckily we have some code duplications:

• There’s a repeating pattern in our tests: instantiation of the class under test (CUT).
• The string constant ’1042′ appears in both the test and the code!

In the Refactoring phase, we’re allowed to remove code duplication while keeping the tests pass and the functionality of the code unchanged. Let’s deal with the first problem, PHPUnit offers the setUp() method for that:

class TimeValidatorTest extends PHPUnit_Framework_TestCase
{
    public function setUp()
    {
        $this->validator = new TimeValidator();
    }

    public function test24HourFormatIsAccepted()
    {
        $this->assertTrue($this->validator->isValid('10:42'));
    }

    public function testTimeSpecificationMustContainOneColon()
    {
        $this->assertFalse($this->validator->isValid('1042'));
    }

    private $validator;
}

That was piece of cake, now let’s clean the production code! The simplest PHP line that came to my mind to make both testcases pass without the dirty hack of repeating constants in the production code used by the tests to check the behavior of the code, was an strpos() call. But knowing that in the end I want to see a regular expression doing the work, I used an equivalent regexp matching instead:

class TimeValidator
{
    public function isValid($time_specification)
    {
        return preg_match('/:/', $time_specification) == 1;
    }
}

The tests still pass, so it’s time to look for more difficult cases. (And speed things up a little bit.)

Only one colon

The next test that came to my mind was to see if the regexp can deal with two colons:

public function testTimeSpecificationMustContainOneColon()
{
    $this->assertFalse($this->validator->isValid('1042'));
    $this->assertFalse($this->validator->isValid('10::42'));
}

Red phase again, but it’s not very difficult to get into Green:

public function isValid($time_specification)
{
    return preg_match('/^[^:]*:[^:]*$/', $time_specification) == 1;
}

Now we look for exactly one colon from the beginning of the string to the very end. And we’re in Green! Anything to refactor here? Yes, duplicated non-trivial code appears in the regular expression! Let’s get rid of it:

public function isValid($time_specification)
{
    $not_colon = '[^:]*';
    return preg_match(
        "/^$not_colon:$not_colon\$/",
        $time_specification
    ) == 1;
}

The tests still pass. Now there is still repeated code in the regular expression and to make things worse, it got longer, but this will move us forward, so knowing what to come, it’s a good idea to extract that little piece. Besides, the variable explains pretty well what the expression does. Anything else to refactor? Maybe a dataProvider would help eliminating the two almost identical lines from the tests, but I’m lazy now. I promise the next time I’m gonna write a similar assertion, I’ll do clean up the tests.

Hours must be numeric

The next simpliest test that came to my mind was:

public function testHoursMustBeNumeric()
{
    $this->assertFalse($this->validator->isValid('ab:42'));
}

Now we’re in Red, but it seems the next Refactoring phase will be a nice opportunity to get back to that promise.

How to fix that? I know I want to validate hours, so I’m going to create a new variable to be substituted into the regular expression:

public function isValid($time_specification)
{
    $hours = '[0-9]*';
    $not_colon = '[^:]*';
    return preg_match(
        "/^$hours:$not_colon\$/",
        $time_specification
    ) == 1;
}

The new variable is called hours and it matches any sequence of numbers. Yeah, Green again! That was just a matter of seconds. So anything to refactor here? Yes, remember what I promised a few minutes ago:

/**
 * @dataProvider provideInvalidTimeSpecifications
 */
public function testInvalidTimeSpecificationsAreNotAccepted($time_specification)
{
    $this->assertFalse($this->validator->isValid($time_specification));
}

public function provideInvalidTimeSpecifications()
{
    return array(
        'Time specification must contain at least one colon' => array('1042'),
        'Time specification must contain at most one colon' => array('10::42'),
        'Hours must be numeric' => array('ab:42'),
    );
}

Hours must be less than 24

Regardless of 12 hour time format, the hours part must be less than 24. This assertion is simple enough to create a new testcase from it:

public function provideInvalidTimeSpecifications()
{
return array(
    'Time specification must contain at least one colon' => array('1042'),
    'Time specification must contain at most one colon' => array('10::42'),
    'Hours must be numeric' => array('ab:42'),
    'Hours must be less than 24' => array('24:42'),
);
}

And the code that passes all the tests so far is not a big deal either:

public function isValid($time_specification)
{
    $hours = '([0-1]?[0-9]|2[0-3])';
    $not_colon = '[^:]*';
    return preg_match(
        "/^$hours:$not_colon\$/",
        $time_specification
    ) == 1;
}

Anything to refactor? Nope I guess.

Minutes must be numeric

One more simple testcase, just to see how well minutes are validated:

public function provideInvalidTimeSpecifications()
{
    return array(
        'Time specification must contain at least one colon' => array('1042'),
        'Time specification must contain at most one colon' => array('10::42'),
        'Hours must be numeric' => array('ab:42'),
        'Hours must be less than 24' => array('24:42'),
        'Minutes must be numeric' => array('10:ab'),
    );
}

Getting from Red to Green is children’s play as well, I did the same as in the case of the hours. Minutes are validated to be numeric, then a new testcase to make sure they are less than 60:

public function provideInvalidTimeSpecifications()
{
    return array(
        'Time specification must contain at least one colon' => array('1042'),
        'Time specification must contain at most one colon' => array('10::42'),
        'Hours must be numeric' => array('ab:42'),
        'Hours must be less than 24' => array('24:42'),
        'Minutes must be numeric' => array('10:ab'),
        'Minutes must be less than 60' => array('10:60'),
    );
}

And the code:

public function isValid($time_specification)
{
    $hours = '([0-1]?[0-9]|2[0-3])';
    $minutes = '([0-5]?[0-9])';
    return preg_match(
        "/^$hours:$minutes\$/",
        $time_specification
    ) == 1;
}

Anything to refactor? Not a single bit! Notice how nicely that ugly $not_colon variable disappeard? The regular expression is quite self-explanatory, it doesn’t even need a comment to be understandable.

Two digits

Both hours and minutes should be expected to be two digits:

public function provideInvalidTimeSpecifications()
{
    return array(
        'Time specification must contain at least one colon' => array('1042'),
        'Time specification must contain at most one colon' => array('10::42'),
        'Hours must be numeric' => array('ab:42'),
        'Hours must be less than 24' => array('24:42'),
        'Minutes must be numeric' => array('10:ab'),
        'Minutes must be less than 60' => array('10:60'),
        'Hours must be two-digit' => array('1:42'),
        'Minutes must be two-digit' => array('10:4'),
    );
}

Okay, those are two tests at the same time, but TDD allows you to go in your own tempo as long as you can clearly see the small, trivial steps you join together to take a bigger leap. In this case, the two tests are nearly identical, and the fix for them is similar as well: we only have to remove two question marks (why the hell did I write them in the first place?):

public function isValid($time_specification)
{
    $hours = '([0-1][0-9]|2[0-3])';
    $minutes = '([0-5][0-9])';
    return preg_match(
        "/^$hours:$minutes\$/",
        $time_specification
    ) == 1;
}

There’s no doubt that the trivial steps joined together here are visible for everyone, so let’s move on. What to refactor now? I can’t see anything.

The good news is that we are now validating 24 hour format time specifications and our code is still readable, even the reqular expression.

The half of 24 is 12

But the work to validate it is going to be at least the double. Let’s start with some positive tests:

public function test12HourFormatIsAccepted()
{
    $this->assertTrue($this->validator->isValid('10:42 AM'));
}

That’s very similar to test24HourFormatIsAccepted(), but we’re not in Red, so we have to write even more code to get into Green!

What is the simplest regular expression that can make our new testcase pass? Yes, it’s only two characters, but a nice facepalm:

public function isValid($time_specification)
{
    $hours = '([0-1][0-9]|2[0-3])';
    $minutes = '([0-5][0-9])';
    return preg_match(
        "/^$hours:$minutes.*\$/",
        $time_specification
    ) == 1;
}

Now we accept any bullshit following a 24 hour format time specification. But we can refactor now:

/**
 * @dataProvider provideValidTimeSpecifications
 */
public function testValidTimeSpecificationsAreAccepted($time_specification)
{
    $this->assertTrue($this->validator->isValid($time_specification));
}

public function provideValidTimeSpecifications()
{
    return array(
        'Simple 24 hour time specification' => array('10:42'),
        'Simple 12 hour time specification' => array('10:42 AM'),
    );
}

Now we’re green, but we’ve just invalidated our assertion about the exactly one colon.

Exactly one colon is allowed

public function provideInvalidTimeSpecifications()
{
    return array(
        'Time specification must contain at least one colon' => array('1042'),
        'Time specification must contain at most one colon' => array('10::42'),
        'Time specification must not contain colon after minutes' => array('10:42:'),
        'Hours must be numeric' => array('ab:42'),
        'Hours must be less than 24' => array('24:42'),
        'Minutes must be numeric' => array('10:ab'),
        'Minutes must be less than 60' => array('10:60'),
        'Hours must be two-digit' => array('1:42'),
        'Minutes must be two-digit' => array('10:4'),
    );
}

The not so beautiful solution can be something like this:

public function isValid($time_specification)
{
    $hours = '([0-1][0-9]|2[0-3])';
    $minutes = '([0-5][0-9])';
    return preg_match(
        "/^$hours:{$minutes}[^:]*\$/",
        $time_specification
    ) == 1;
}

PHP thought I wanted to refer to $minutes as an array, so I put curly braces around the variable.

Now we’re in Green again, so we can refactor the code. First the tests:

public function provideValidTimeSpecifications()
{
    return array(
        '24 hour time specification' => array('10:42'),
        '12 hour time specification in the morning' => array('10:42 AM'),
        '12 hour time specification in the afternoon' => array('10:42 PM'),
    );
}

Okay, I’m cheating. I added another testcase that I know will be helpful later on, but it still passes with our current production code, so it won’t hurt. Apropo, the production code: a minor refactoring might be to reintroduce the variable we’ve deleted a few minutes ago.

public function isValid($time_specification)
{
    $hours = '([0-1][0-9]|2[0-3])';
    $minutes = '([0-5][0-9])';
    $not_colon = '[^:]*';
    return preg_match(
        "/^$hours:$minutes$not_colon\$/",
        $time_specification
    ) == 1;
}

At least it’s readable. Let’s move on, that $not_colon will not haunt us too long.

Bad idea

I want to get rid of $not_colon as soon as possible, so let’s force the evolution of the regexp into a direction that does not involve $not_colon existing any longer. I want a space after the minutes part of the time specification:

public function provideInvalidTimeSpecifications()
{
    return array(
        'Time specification must contain at least one colon' => array('1042'),
        'Time specification must contain at most one colon' => array('10::42'),
        'Time specification must not contain colon after minutes' => array('10:42:'),
        'Hours must be numeric' => array('ab:42'),
        'Hours must be less than 24' => array('24:42'),
        'Minutes must be numeric' => array('10:ab'),
        'Minutes must be less than 60' => array('10:60'),
        'Hours must be two-digit' => array('1:42'),
        'Minutes must be two-digit' => array('10:4'),
        '12 hour time specification must contain a space after minutes' => array('10:42AM'),
    );
}

The first idea that came to my mind to make that pass was to insert a space before $not_colon in the regexp:

"/^$hours:$minutes $not_colon\$/"

That makes the 24 hour format tests fail, so I deleted both the space and the new testcase. Though the new testcase was a teeny-tiny little step, it’d have required bigger changes in the regular expression, namely to separate the two kinds of hour format. Instead I introduced a more strict testcase in provideInvalidTimeSpecifications() that is comparable to the size of the changes to make it pass while not breaking all the other tests:

'12 hour format must end with AM or PM' => array('10:42 XY'),

The production code to pass that test:

public function isValid($time_specification)
{
    $hours = '([0-1][0-9]|2[0-3])';
    $minutes = '([0-5][0-9])';
    $ampm = '( [AP]M)';
    return preg_match(
        "/^$hours:$minutes$ampm?\$/",
        $time_specification
    ) == 1;
}

Reviewing that now I can see I could have made the original testcase pass by applying the same changes I did for this case, but the test I deleted was not suggesting it. It seems to me that TDD is not about coding skills but about testing skills. Writing good code is one thing, but writing good tests that enforce building up good code step-by-step can be at least as much important.

Differentiating 12 hour and 24 hour formats

Time for a bigger change. A new testcase for the negative tests:

'24 hour format must be exactly 5 characters long' => array('14:42 PM'),

To make that pass, the regular expression must recognize the difference between the two kinds of time formats. It requires matching numbers less than 13, but most of the code needed already exists.

public function isValid($time_specification)
{
    $minutes = '([0-5][0-9])';

    $hours_less_than_24 = '([0-1][0-9]|2[0-3])';
    $time_spec_24 = "$hours_less_than_24:$minutes";

    $hours_less_than13 = '(0[0-9]|1[012])';
    $ampm = '( [AP]M)';
    $time_spec_12 = "$hours_less_than13:$minutes$ampm";

    return preg_match(
        "/^($time_spec_24|$time_spec_12)\$/",
        $time_specification
    ) == 1;
}

It seems to be a big change, but actually it’s quite simple: the question mark has been substituted with the two alternatives it specified: one is hour specification without $ampm, the other is the same, but with $ampm. Of course the second alternative should not match hours greater than 12, so it required a second type of hour matching regular expression. When everything worked, some extractions and variable renames were done.

Attempt to write more failing tests

Are we ready? The code in isValid() seems to contain all the information appearing in the requirements, so there must be only a few small steps remaining. Let’s try adding some new tests. These should not be considered valid:

'Hour part of 12 hour format must be less than 13' => array('13:00 PM'),
'12 hour format must be exactly 8 characters long' => array('12:45  AM'),

They pass without touching the code, we couldn’t manage to get into Red. This means there’s some room for further refactoring. All the dirty details of building our regular expressions can go to a private method buried at the bottom of the class:

class TimeValidator
{
    public function isValid($time_specification)
    {
        return preg_match($this->buildRegExp(), $time_specification) == 1;
    }

    private function buildRegExp()
    {
        $minutes = '([0-5][0-9])';

        $hours_less_than_24 = '([0-1][0-9]|2[0-3])';
        $time_spec_24 = "$hours_less_than_24:$minutes";

        $hours_less_than13 = '(0[0-9]|1[012])';
        $ampm = '( [AP]M)';
        $time_spec_12 = "$hours_less_than13:$minutes$ampm";

        return "/^($time_spec_24|$time_spec_12)\$/";
    }
}

Maybe isValid() is easier to read like this:

public function isValid($time_specification)
{
    return 1 == preg_match($this->buildRegExp(), $time_specification);
}

So is there anything to test? Well, I’m sure PHP has a gotcha for us:

'Multiline strings are not accepted' => array("10:42\n"),

Bang, it fails! The fix is very simple:

return "/^($time_spec_24|$time_spec_12)\$/D";

Sometimes it’s worth reading around PCRE modifiers in PHP documentation, just to make time pass faster.

Leading zeros

One more thing I miss: though the code cares about leading zeros, there’s no testcase mentioning them. So these should be valid:

'12 hour time specification with leading zero' => array('00:42 PM'),
'24 hour time specification with leading zero' => array('00:42'),

Doesn’t that 00:42 PM look weird? I’m not used to 12 hour time format, so I had to think about it for a few seconds: in 12 hour notation there’s no such thing as 00:00. Hours can be between 01 and 12, which means that our two new passing tests should look like:

'12 hour time specification with leading zero' => array('01:42 PM'),
'24 hour time specification with leading zero' => array('00:42'),

(Yes, they pass as expected. Note that I forgot this speciality of 12 hour notation when writing the requirements!)

And the bug can be easily triggered by this negative test:

'12 hour time specification does not allow hours to be zero' => array('00:42 PM'

And the code fixing it:

$hours_less_than13 = '(0[1-9]|1[012])';

The whole code

After adding some corner cases to the list of positive tests, the final results are:

TimeValidator.php

class TimeValidator
{
    public function isValid($time_specification)
    {
        return 1 == preg_match($this->buildRegExp(), $time_specification);
    }

    private function buildRegExp()
    {
        $minutes = '([0-5][0-9])';

        $hours_less_than_24 = '([0-1][0-9]|2[0-3])';
        $time_spec_24 = "$hours_less_than_24:$minutes";

        $hours_less_than13 = '(0[1-9]|1[012])';
        $ampm = '( [AP]M)';
        $time_spec_12 = "$hours_less_than13:$minutes$ampm";

        return "/^($time_spec_24|$time_spec_12)\$/D";
    }
}

TimeValidatorTest.php

class TimeValidatorTest extends PHPUnit_Framework_TestCase
{
    public function setUp()
    {
        $this->validator = new TimeValidator();
    }

    /**
     * @dataProvider provideValidTimeSpecifications
     */
    public function testValidTimeSpecificationsAreAccepted($time_specification)
    {
        $this->assertTrue($this->validator->isValid($time_specification));
    }

    public function provideValidTimeSpecifications()
    {
        return array(
            '24 hour time specification' => array('10:42'),
            '12 hour time specification in the morning' => array('10:42 AM'),
            '12 hour time specification in the afternoon' => array('10:42 PM'),
            '12 hour time specification with leading zero' => array('01:42 PM'),
            '24 hour time specification with leading zero' => array('00:42'),
			'First minute of a 24 hour specification' => array('00:00'),
            'First minute of a 12 hour specification' => array('01:00 AM'),
            'Last 12 hour time specification in the morning' => array('12:59 AM'),
            'Last 12 hour time specification in the afternoon' => array('12:59 PM'),
            'Last 24 hour time specification' => array('23:59'),
        );
    }

    /**
     * @dataProvider provideInvalidTimeSpecifications
     */
    public function testInvalidTimeSpecificationsAreNotAccepted($time_specification)
    {
        $this->assertFalse($this->validator->isValid($time_specification));
    }

    public function provideInvalidTimeSpecifications()
    {
        return array(
            'Time specification must contain at least one colon' => array('1042'),
            'Time specification must contain at most one colon' => array('10::42'),
            'Time specification must not contain colon after minutes' => array('10:42:'),
            'Hours must be numeric' => array('ab:42'),
            'Hours must be less than 24' => array('24:42'),
            'Minutes must be numeric' => array('10:ab'),
            'Minutes must be less than 60' => array('10:60'),
            'Hours must be two-digit' => array('1:42'),
            'Minutes must be two-digit' => array('10:4'),
            '12 hour format must end with AM or PM' => array('10:42 XY'),
            '24 hour format must be exactly 5 characters long' => array('14:42 PM'),
            'Hour part of 12 hour format must be less than 13' => array('13:00 PM'),
            '12 hour format must be exactly 8 characters long' => array('12:45  AM'),
            'Multiline strings are not accepted' => array("10:42\n"),
            '12 hour time specification does not allow hours to be zero' => array('00:42 PM'),
        );
    }

    private $validator;
}

You can check them out at GitHub.

Conclusion

The whole code copied above took about 45-60 minutes to write (including taking notes for this blog post), during which I’ve learnt a lot of things about practising TDD. I’m sure that if I tried to reproduce this experiment from scratch, it would take several steps less while still moving with teeny-tiny steps forward.

Just as any part of code, regular expressions also worth writing a bunch of unit tests that make sure that the code can be changed anytime later, either to fix bugs or to extend functionality. The big advantage of unit tests (besides architectural flexibility, documentation, etc.) is not that they can expose any possible bug that can be imagined but they allow the code to be changed without worrying much about breaking existing, well-tested functionality.

But there are some gotchas in the field as well:

• There’s no tool to measure coverage for regular expressions that I’m aware of at the moment. The most useful hit I found with Google doesn’t help much either.
• It’s very easy to overlook bugs and miss testcases during test-driving regular expressions. (When the regexp engine that comes bundled with your language has some gotchas to offer, well, that doesn’t make the situation much better.)
• One character change in the regular expression may require a bunch of new testcases to be written.