Posts Tagged ‘unit test’

Game of life – never getting boring

Thursday, May 31, 2012 @ 09:05 PM Author: athos

Do you think it’s funny to implement Conway’s Game of Life for the 20th time? According to my experiences, the answer is hell yeah!

Since the Global Day of CodeRetreat event (organized by Marton Meszaros in Hungary), I’m a big fan of the CodeRetreat format of coding dojos. I’ve been attending all the events of the CodeRetreat Budapest Community, and at the last one, I even helped coaching during some of the sessions. Nucc and me decided to introduce this event to our fellow developers at BalaBit as well and fortunately the management was kind enough to support us by dedicating some working hours to learn about TDD and other modern software development methodologies.

At a CodeRetreat event, you always implement the four rules of Game of Life (without UI and such fancy stuff). Doing the same task again and again makes the problem well-known and understood so you can focus on the style and design of your tests and code, which is the goal of a CodeRetreat. You don’t have to finish the implementation, though, it’s not about Getting Things Done or competing which pair is the first to finish. More like Not Getting Things Done. Often it’s impossible as well to finish for you have only 45 minutes to work. After that, well, code is deleted, a short retrospective meeting is held then a new session begins. Pair programming is mandatory, and by changing the pairs after every session you’re guaranteed to learn a lot from others. To make sure that you won’t be able to train yourself during the day to finish new constraints are introduced in every session, like infinite grid, immutability of states, 3 line methods with at most 2 parameters, no-mouse (did you notice you go faster when you use only keyboard shortcuts in your IDE?), etc..

During the first few sessions, there are no constraints. The goal is getting the problem understood. In the implementation, you just do whatever you want. That seems to be the hardest constraint though, since people tend to not finish during the first sessions. Instead they do Big Design Up Front and forget to care about the software to be implemented. These are the sessions where nice UML diagrams about Cells and Neighborhood relations and Worlds and Games and Rules and such nicely designed stuff are drawn, then people realize after 45 minutes that they spent almost an hour working on getters and setters but not a single rule of the game got implemented. Yep, there’s a reason for the Four Rules of Simple Design having been invented. ;-)

Turns out if you’d started the very first testcase with the first rule (“Any live cell with fewer than two live neighbours dies, as if caused by under-population”), you might have had a working implementation of all four of them after 15-20 minutes or so. And nothing more than that since you wouldn’t have written code that is never used except for making those UMLs feel more complete. YAGNI!

Of course there’s a chance that such a quick and dirty implementation will be, well, dirty. It may contain at least one thing you consider ugly. But you have more than half of the session left and the safety net of a bunch of tests to refactor the hell out of it!

You spoiled the public interface of your Game with methods that should belong to a class named Board or World or Map instead? Are you feeling the need to test a method that is declared private? After extracting such methods into a separate class, you might end up with a Game class that has no state at all and contains only one public method that just creates new generations of cells based on a previous one.

On the other hand, after realizing how over-engineering slows them down, many people try to continue with sloppy design, skipping the refactorings for example to get rid of language primitives in the most abstract levels of the business logic or to conform to the SOLID principles, etc. They can be forced to do so by introducing requirement change surprises. For example, to handle hexagon maps along with square grids, a Topology or similar interface has to be extracted from the class representing the board, which can encapsulate the details of coordinate systems and neighborhood relations between coordinates. (Did you notice that the rules of the game do not depend on the placement and shape of the neighbors nor the neighbors themselves, but only their count is what matters?) To handle colored cells which know how old they are, cells have to be represented by a separate class instead of bare coordinate-tuples or boolean flags.

Such refactorings can be a pain in the ass when tests contain copy&paste, duplication, redundancy and duplication, so they must be cleaned up as well: by extracting common fixtures, creating abstract assertions based on the repeating patterns of similar assertions, etc. (Abstract assertions even help you to conform to such rigorous principles like “1 assertion per test.”)

Imagine your day to day software development work boiling down to such simple business requirements implemented by a couple of short but well named methods in a few simple and minimalistic classes, all of them thoroughly unit tested (by unit testing I mean unit testing), all of those tests proven to be useful (since you’ve seen them fail and turning into green a couple of seconds later) and providing 100% coverage of assertions. Wouldn’t it be easier than digging yourself through stack traces in mindblowingly complex codes full of nested infinite-but-conditionally-breaking-somewhere-in-the-middle-do-while loops depending on side effects of getter functions and badly named global variables coming from a dozen layers away? If you know this feeling I’m talking about, I’d recommend you to visit the next CodeRetreat near your location (look around in Twitter or Facebook) – to try something new!

IOCCC vs Clean Code

Sunday, November 27, 2011 @ 10:11 PM Author: athos

I found this piece of code at the website of the International Obfuscated C Code Contest. (Did you know the contest is open for this year?) Since I read tons of books and papers about clean code nowadays, I couldn’t resist refactoring it, just to see how much a heavy code cleanup can improve a source code that was intentionally written to be obscrure as possible, and of course, to abuse both IOCCC and Clean Code as hard as can be. :-)

The original code

main(n,i,a,m){while(i=++n)
for(a=0;a<i?a=a*8+i%8,i/=8,m=a==i|a/8==i,1:(n-++m||printf("%o\n",n))&&n%m;);}

To compile it using GCC, the following command can be used:

$ gcc -ansi -o makarios makarios.c

The only thing it does is slowly printing a bunch of numbers to stdout in an infinite loop. Note that this is pretty much all the information that can be extracted from the code at first blink, either by running it or by reading it.

Refactoring without tests is suicide

Before refactoring it, I needed to make it testable. Since this is a very simple program, I decided to test it end-to-end, by saving a reference output to a textfile (say, for example, the first 150 numbers it prints) and by breaking the infinite loop (of course it would terminate once n overflows, but that’s way too slow):

main(n,i,a,m){while(i=++n)
#define STOP_AT 522233

main(n,i,a,m){while((i=++n) <= STOP_AT)
for(a=0;a<i?a=a*8+i%8,i/=8,m=a==i|a/8==i,1:(n-++m||printf("%o\n",n))&&n%m;);}

Note that it prints numbers in octal base, and 522233 is the 150th number in the reference output in decimal base. It could’ve been written in octal, but in the end I’d like to get rid of this hard-coded constant, so it will do the job well for now. Let’s see if it still generates the expected output:

$ gcc -ansi -Wall -o ./makarios makarios.c \
      && ./makarios 2>&1 \
      | diff expected_output.txt - \
      && echo OK

After each and every change, I ran the test and created a patch only if the test passed. (Find the individual patches at GitHub.)

Recovering structure

So do you have any idea how this code works? Me neither. But there are a couple of things to note:

  • Some indentation might come handy in the future.
  • Local variables are defined as arguments to main(), OMG!
  • The output depends on n (which will always be the number of command line arguments to the program), but all the other variables are overwritten sooner or later, before used. (a and i are trivial to see, and since i is always positive and a is 0, a<i will always be true in the beginning of the inner loop, so the positive branch of the ternary is executed first, which means m gets overwritten as well).
  • Easy to see by experiment, this program does not print numbers smaller than the number of command line arguments (note that the output is in octal base), so if one would want to see only numbers greater than eg. 64 (100 in octal base), the program should be invoked like this:
    ./makarios `seq 1 64`

    This is not very useful, so I decided to drop this feature. Variable n will start from 1, like when the program is invoked without arguments (making the first parameter of main() be 1).

  • There are a couple of compiler warnings, these are better cleaned up so we can see if we mess up something.

After a couple of minutes, my code looked like this:

#include <stdio.h>

#define STOP_AT 522233

main(n,i,a,m){while((i=++n) <= STOP_AT)
for(a=0;a<i?a=a*8+i%8,i/=8,m=a==i|a/8==i,1:(n-++m||printf("%o\n",n))&&n%m;);}
int main(int argc, char* argv[])
{
    int n = 1,
        i, a, m;

    while((i=++n) <= STOP_AT)
    {
        for(a=0;a<i?a=a*8+i%8,i/=8,m=a==i|a/8==i,1:(n-++m||printf("%o\n",n))&&n%m;)
        {
        }
    }

    return 0;
}

Next I converted the for loop into a while loop and moved a and m inside the outer loop since they are not used outside of it:

#include <stdio.h>

#define STOP_AT 522233

int main(int argc, char* argv[])
{
    int n = 1,
        i, a, m;
        i;

    while((i=++n) <= STOP_AT)
    {
        for(a=0;a<i?a=a*8+i%8,i/=8,m=a==i|a/8==i,1:(n-++m||printf("%o\n",n))&&n%m;)
        int a = 0,
            m;

        while (a<i?a=a*8+i%8,i/=8,m=a==i|a/8==i,1:(n-++m||printf("%o\n",n))&&n%m)
        {
        }
    }

    return 0;
}

Now if that ugly expression in the condition of the loop would be inside the block, it could be easily broken up:


int a = 0,
    m;
    m, is_not_ready;

while (a<i?a=a*8+i%8,i/=8,m=a==i|a/8==i,1:(n-++m||printf("%o\n",n))&&n%m)
}
do
{
    is_not_ready = a<i?a=a*8+i%8,i/=8,m=a==i|a/8==i,1:(n-++m||printf("%o\n",n))&&n%m;
} while (is_not_ready);

First, replace the ternary with an if statement:

do
{
    is_not_ready = a<i?a=a*8+i%8,i/=8,m=a==i|a/8==i,1:(n-++m||printf("%o\n",n))&&n%m;
    if (a < i)
    {
        is_not_ready = a=a*8+i%8,i/=8,m=a==i|a/8==i,1;
    }
    else
    {
        is_not_ready = (n-++m||printf("%o\n",n))&&n%m;
    }
} while (is_not_ready);

Notice that I did not even try to understand the hows and whys. The only thing I did so far was to analyze the code, breaking up expressions, replacing them to more readable alternatives, but I have no ghost of an idea what this code does and why it does it so. Let’s continue the work by breaking up the assignment in the true branch of the if statement (from now on, a good cheat sheet of operator precedence will be a life saver):

if (a < i)
{
    is_not_ready = a=a*8+i%8,i/=8,m=a==i|a/8==i,1;
    a = a*8 + i%8;
    i /= 8;
    m = (a == i) | (a/8 == i);
    is_not_ready = 1;
}
else
{
    is_not_ready = (n-++m||printf("%o\n",n))&&n%m;
}

Notice the value assigned to m? Those are two booleans with a binary OR in the middle. That’s ugly, using a logical operator instead will change nothing:

m = (a == i) | (a/8 == i);
m = (a == i) || (a/8 == i);

Now breaking up the assignments inside the else block: printf() will always return non-zero making the expression inside parenthesis true, so is_not_ready depends only from n%m. Since it’s a boolean expression, I added a comparison to zero:

is_not_ready = (n-++m||printf("%o\n",n))&&n%m;
(n-++m||printf("%o\n",n));
is_not_ready = 0 != n%m;

Due to lazy evaluation, printf() is only executed when n-++m equals to zero. To make that expressed in code, an if statement can be used instead of the ignored boolean expression:

(n-++m||printf("%o\n",n));
if (0 == n-++m)
    printf("%o\n", n);

is_not_ready = 0 != n%m;

To make the condition more readable:

if (0 == n-++m)
if (++m == n)
    printf("%o\n", n);

So far, so good:


#include <stdio.h>

#define STOP_AT 522233

int main(int argc, char* argv[])
{
    int n = 1,
        i;

    while((i=++n) <= STOP_AT)
    {
        int a = 0,
            m, is_not_ready;

        do
        {
            if (a < i)
            {
                a = a*8 + i%8;
                i /= 8;
                m = (a == i) || (a/8 == i);
                is_not_ready = 1;
            }
            else
            {
                if (++m == n)
                    printf("%o\n", n);

                is_not_ready = 0 != n%m;
            }
        } while (is_not_ready);
    }

    return 0;
}

This is kinda readable, isn’t it? No! This is not much better than it was in its 105 bytes size.

Let’s do some Command-query separation here by extracting state-changing operations from conditionals.

if (++m == n)
++m;
if (m == n)
    printf("%o\n", n);

Pretty straightforward. Now ++n and the assignment to i require slightly more work:

int main(int argc, char* argv[])
{
    int n = 1,
        i;
    int n = 2;

    while((i=++n) <= STOP_AT)
    while(n <= STOP_AT)
    {
        int a = 0,
            i = n,
            m, is_not_ready;

        do
        {
            if (a < i)
            {
                a = a*8 + i%8;
                i /= 8;
                m = (a == i) || (a/8 == i);
                is_not_ready = 1;
            }
            else
            {
                ++m;
                if (m == n)
                    printf("%o\n", n);

                is_not_ready = 0 != n%m;
            }
        } while (is_not_ready);

        ++n;
    }

    return 0;
}

Actually the outer loop can be written shorter as a for loop:

int main(int argc, char* argv[])
{
    int n = 2;
    int n;

    while(n <= STOP_AT)
    for (n = 2; n <= STOP_AT; ++n)
    {
        int a = 0,
            i = n,
            m, is_not_ready;

        do
        {
            if (a < i)
            {
                a = a*8 + i%8;
                i /= 8;
                m = (a == i) || (a/8 == i);
                is_not_ready = 1;
            }
            else
            {
                ++m;
                if (m == n)
                    printf("%o\n", n);

                is_not_ready = 0 != n%m;
            }
        } while (is_not_ready);
        ++n;
    }

    return 0;
}

Now we can get rid of is_not_ready, it was just a temporary helper to break up some magical expressions:


for (n = 2; n <= STOP_AT; ++n)
{
    int a = 0,
        i = n,
        m, is_not_ready;
        m;

    do
    {
        if (a < i)
        {
            a = a*8 + i%8;
            i /= 8;
            m = (a == i) || (a/8 == i);
            is_not_ready = 1;
        }
        else
        {
            ++m;
            if (m == n)
                printf("%o\n", n);

            is_not_ready = 0 != n%m;
            if (0 == n%m)
                break;
        }
    } while (is_not_ready);
    } while (1);
}

For an infinite loop, it does not make much difference if it’s a post-test or a pre-test:

do
while (1)
{
    if (a < i)
    {
        a = a*8 + i%8;
        i /= 8;
        m = (a == i) || (a/8 == i);
    }
    else
    {
        ++m;
        if (m == n)
            printf("%o\n", n);

        if (0 == n%m)
            break;
    }
} while (1);
}

If you look at carefully, that’s two inner loops for the price of one:

  • Variable a is starting from 0 and is compared to i which is always positive. This implies that in every iteration of the outer loop the positive branch of the if statement is executed first.
  • The negative branch of the if statement changes neither variables read by the positive branch, nor those used in the condition.
  • In other words, once the negative branch is executed during an iteration of the outer loop, the positive one is never executed again in that iteration.
  • These together imply that in every iteration of the outer loop, the positive branch of the if statement is executed some times, then the negative branch, which finally exits from the inner loop. I.e. during execution, practically there are two separate loops.
  • Separating them in code as well makes understanding the behavior of the program easier.
while (1)
{
    if (a < i)
    while (a < i)
    {
        a = a*8 + i%8;
        i /= 8;
        m = (a == i) || (a/8 == i);
    }
    else
    while (1)
    {
        ++m;
        if (m == n)
            printf("%o\n", n);

        if (0 == n%m)
            break;
    }
}

Now the last compiler warning can be easily eliminated once we notice that m is not used inside the first inner loop, but it’s always overwritten before evaluating the loop condition again, which means it can be extracted to be after the loop (knowing that for every possible values of i and a the loop iterates at least one, so m is never uninitialized before the second inner loop).

while (a < i)
{
    a = a*8 + i%8;
    i /= 8;
    m = (a == i) || (a/8 == i);
}
m = (a == i) || (a/8 == i);

Now let’s take care of the second inner loop! Reverting back to a post-test loop (getting rid of always true conditional):

while (1)
do
{
    ++m;
    if (m == n)
        printf("%o\n", n);

    if (0 == n%m)
        break;
}
} while (0 != n%m);

Notice that conditional printing can be extracted because the loop will either exit before the condition of printing could become true or increment m until it reaches n, but when the latter happens, the loop will break anyways.

do
{
    ++m;
    if (m == n)
        printf("%o\n", n);
} while (0 != n%m);

if (m == n)
    printf("%o\n", n);

Now m is used in two roles: sometimes it holds a boolean value, sometimes it’s used in arithmetical expressions. This violates Single Responsibility Principle, so let’s get rid of one of the roles. Notice that when m is 0, the do-while loop will iterate only once, and then no printing will happen since n is always greater than 1 and m will be equal to 1, and 1 is a divisor of any n. Which means we can skip the do-while loop when the magical expression after the first inner loop is false, and start m from 1 when it’s not:

m = (a == i) || (a/8 == i);
if (!((a == i) || (a/8 == i)))
    continue;
m = 1;

There’s one more tiny thing disturbing me: I don’t really like post-test loops when they’re used unnecessarily, so let’s get rid of this one:

m = 1;
do
m = 2;
while (0 != n%m)
{
    ++m;
} while (0 != n%m);
}

The code so far:

#include <stdio.h>

#define STOP_AT 522233

int main(int argc, char* argv[])
{
    int n;

    for (n = 2; n <= STOP_AT; ++n)
    {
        int a = 0,
            i = n,
            m;

        while (a < i)
        {
            a = a*8 + i%8;
            i /= 8;
        }

        if (!((a == i) || (a/8 == i)))
            continue;

        m = 2;
        while (0 != n%m)
        {
            ++m;
        }

        if (m == n)
            printf("%o\n", n);
    }

    return 0;
}

Cleaning the code

Now that’s clean, isn’t it? Of course not! For instance, nothing in it has a nice, explanatory name. It’s just a messy mix of one-letter variables, magical expressions and a spaghetty of loops.

Notice that m is only used in the second half of the outer loop starting from the assignment and ending at the conditional of the if statement. If those lines would be in a separate function, m could be a local variable and n would be a parameter. Similar can be done for the first part starting from the declaration of a and i and ending at the first if statement. Note that the two loops have no variables in common, but both can be parametrized by n. Let’s move those loops into functions in the hope they will be easier to understand without their disturbing contexts:

#include <stdio.h>

#define STOP_AT 522233

static int magic_algorithm(int number);
static int other_magic_algorithm(int number);
static void print_octal(int number);

int main(int argc, char* argv[])
{
    int n;

    for (n = 2; n <= STOP_AT; ++n)
    {
        int a = 0,
            i = n,
            m;
        while (a < i)
        {
            a = a*8 + i%8;
            i /= 8;
        }

        if (!((a == i) || (a/8 == i)))
        if (!magic_algorithm(n))
            continue;

        m = 2;
        while (0 != n%m)
        {
            ++m;
        }

        if (m == n)
            printf("%o\n", n);
        if (other_magic_algorithm(n))
            print_octal(n);
    }
    return 0;
}

static int
magic_algorithm(int number)
{
    int a = 0,
        i = number;
    while (a < i)
    {
        a = a*8 + i%8;
        i /= 8;
    }

    return (a == i) || (a/8 == i);
}

static int
other_magic_algorithm(int number)
{
    int m;

    m = 2;
    while (0 != number%m)
    {
        ++m;
    }

    return m == number;
}

static void
print_octal(int number)
{
    printf("%o\n", number);
}

That printf() with the format string are ugly implementation details that shoul be buried inside a small, well named function somewhere at the bottom.

The first loop is called magic_algorithm() and the second is other_magic_algorithm() from now. I’m sure they could be given more rational names, but coming up with better names would require understanding the code, which I don’t want to do without making it obvious at the same time, so let’s continue refactoring.

The easiest thing to do is simplifying main() by joining the two if statements:

for (n = 2; n <= STOP_AT; ++n)
{
    if (!magic_algorithm(n))
        continue;

    if (other_magic_algorithm(n))
    if (magic_algorithm(n) && other_magic_algorithm(n))
        print_octal(n);
}

Now main() is pretty obvious to understand: it prints numbers that are accepted by both of our magic algorithms in octal format. The question is, what and how do these magic algorithms do?

The second is simplier: by extracting the condition of the while loop into a well named function, it becomes almost obvious:

static int is_divisable(int dividend, int divisor);

static int
other_magic_algorithm(int number)
{
    int m;

    m = 2;
    while (0 != number%m)
    while (!is_divisable(number, m))
    {
        ++m;
    }

    return m == number;
}

static int
is_divisable(int dividend, int divisor)
{
    /* FIXME: handle division by zero */
    return 0 == dividend % divisor;
}

Note that there’s a reason this function is static: it’s not reusable, becuase it does not handle unexpected input, that’s why a FIXME comment is added. Now let’s focus on refactoring.

After extracting is_divisable(), the role of m becomes clear, so let’s find a good name for it:

static int
other_magic_algorithm(int number)
{
    int m;
    int smallest_divisor = 2;

    m = 2;
    while (!is_divisable(number, m))
    while (!is_divisable(number, smallest_divisor))
    {
        ++m;
        ++smallest_divisor;
    }

    return m == number;
    return smallest_divisor == number;
}

What do you call a number that equals to its smallest divisor greater than 1?

#include <stdio.h>

#define STOP_AT 522233

static int magic_algorithm(int number);
static int other_magic_algorithm(int number);
static int is_prime(int number);
static void print_octal(int number);

int main(int argc, char* argv[])
{
    int n;

    for (n = 2; n <= STOP_AT; ++n)
    {
        if (magic_algorithm(n) && other_magic_algorithm(n))
        if (magic_algorithm(n) && is_prime(n))
            print_octal(n);
    }

    return 0;
}

static int is_divisable(int dividend, int divisor);

static int
other_magic_algorithm(int number)
is_prime(int number)
{
    int smallest_divisor = 2;

    while (!is_divisable(number, smallest_divisor))
    {
        ++smallest_divisor;
    }

    return smallest_divisor == number;
}

Do you see Single Responsibility Principle being violated? I do:

static int is_divisable(int dividend, int divisor);
static int find_smallest_divisor_greater_than_one(int number);

static int
is_prime(int number)
{
    /* FIXME: handle 0 and 1 */
    return find_smallest_divisor_greater_than_one(number) == number;
}

static int is_divisable(int dividend, int divisor);

static int
find_smallest_divisor_greater_than_one(int number)
{
    /* FIXME: handle negative numbers */

    int smallest_divisor = 2;

    while (!is_divisable(number, smallest_divisor))
    {
        ++smallest_divisor;
    }

    return smallest_divisor == number;
    return smallest_divisor;
}

Finding the smallest divisor and deciding if a number is prime are at different abstraction levels. Besides, it was never mentioned in the code that 1 is not considered a divisor.

Don’t worry about function call overhead, the first thing compilers will do when encountering this code will be to make is_divisable() and find_smallest_divisor_greater_than_one() inline. Then why did we extract them? Because this code is being written for humans, not compilers!

Now to the other magic function.

What is 42 % 10? It’s 2 of course. What is X % 10? Yes, it’s the last digit of X in base 10. Now replace 10 with 8, and you’re doing the same in octal base. This may help a lot to understand what to extract from the other magic algorithm and how to name the functions extracted:

static int get_last_octal_digit(int number);
static int remove_last_octal_digit(int number);

static int
magic_algorithm(int number)
{
    int a = 0,
        i = number;
        i = number,
        digit;

    while (a < i)
    {
        a = a*8 + i%8;
        i /= 8;
        digit = get_last_octal_digit(i);
        a = a*8 + digit;
        i = remove_last_octal_digit(i);
    }

    return (a == i) || (a/8 == i);
    return (a == i) || (remove_last_octal_digit(a) == i);
}

static int
get_last_octal_digit(int number)
{
    return number % 8;
}

static int
remove_last_octal_digit(int number)
{
    return number / 8;
}

This starts to make sense, so let’s continue with this octal digit theory:


static int get_last_octal_digit(int number);
static int append_octal_digit(int number, int digit);
static int remove_last_octal_digit(int number);

static int
magic_algorithm(int number)
{
    int a = 0,
        i = number,
        digit;

    while (a < i)
    {
        digit = get_last_octal_digit(i);
        a = a*8 + digit;
        a = append_octal_digit(a, digit);
        i = remove_last_octal_digit(i);
    }

    return (a == i) || (remove_last_octal_digit(a) == i);
}

static int
get_last_octal_digit(int number)
{
    return number % 8;
}

static int
append_octal_digit(int number, int digit)
{
    /* FIXME: handle invalid digits */
    return number * 8 + digit;
}

static int
remove_last_octal_digit(int number)
{
    return number / 8;
}

(Sorry, that’s another FIXME added.)

Now the roles of those variables are getting clearer: in every iteration, a digit is removed from the end of i and is appended to the end of a. This will make a contain the digits of the given number in reversed order, though the algorithm is stopped when reaching the digit in the middle.

static int get_last_octal_digit(int number);
static int append_octal_digit(int number, int digit);
static int remove_last_octal_digit(int number);

static int
magic_algorithm(int number)
{
    int a = 0,
        i = number,
        digit;
    int reversed_digits = 0,
        remaining_digits = number;

    while (a < i)
    while (reversed_digits < remaining_digits)
    {
        digit = get_last_octal_digit(i);
        a = append_octal_digit(a, digit);
        i = remove_last_octal_digit(i);
        int digit = get_last_octal_digit(remaining_digits);
        reversed_digits = append_octal_digit(reversed_digits, digit);
        remaining_digits = remove_last_octal_digit(remaining_digits);
    }

    return (a == i) || (remove_last_octal_digit(a) == i);
    return (reversed_digits == remaining_digits)
        || (remove_last_octal_digit(reversed_digits) == remaining_digits);
}

When the digits of a number in a base remain the same when the order is reversed, then the number is called palindromic in that base. This algorithm is a test for the octal base. Note that the algorithm stops moving the digits when it reaches the one in the middle. That’s why the expression in the return statement is built from two parts: one is for an odd number of digits, the other is for the even case. This is enough to rename magic_algorithm() (oops, I noticed a new FIXME again):

#include <stdio.h>

#define STOP_AT 522233

static int magic_algorithm(int number);
static int is_palindromic_in_octal_base(int number);
static int is_prime(int number);
static void print_octal(int number);

int main(int argc, char* argv[])
{
    int n;

    for (n = 2; n <= STOP_AT; ++n)
    {
        if (magic_algorithm(n) && is_prime(n))
        if (is_palindromic_in_octal_base(n) && is_prime(n))
            print_octal(n);
    }

    return 0;
}

static int get_last_octal_digit(int number);
static int append_octal_digit(int number, int digit);
static int remove_last_octal_digit(int number);

static int
magic_algorithm(int number)
is_palindromic_in_octal_base(int number)
{
    /* FIXME: handle negative numbers */

    int reversed_digits = 0,
        remaining_digits = number;

    while (reversed_digits < remaining_digits)
    {
        int digit = get_last_octal_digit(remaining_digits);
        reversed_digits = append_octal_digit(reversed_digits, digit);
        remaining_digits = remove_last_octal_digit(remaining_digits);
    }

    return (reversed_digits == remaining_digits)
        || (remove_last_octal_digit(reversed_digits) == remaining_digits);
}

static int
get_last_octal_digit(int number)
{
    return number % 8;
}

static int
append_octal_digit(int number, int digit)
{
    /* FIXME: handle invalid digits */
    return number * 8 + digit;
}

static int
remove_last_octal_digit(int number)
{
    return number / 8;
}

Now the while loop could be extracted from is_palindromic_in_octal_base() (remember SRP?), but that would require:

  • output parameters: ugly
  • iterating through the whole number to calculate reversed order to the end: might be slow, notice that the original author might have done it this way to save half of the steps
  • structs and pointers: overkill
  • macro magic: can be confusing

In short: the code is not clean, but we cannot refactor it better. Let’s admit this failure by adding some explanatory comments to this function:

static int
is_palindromic_in_octal_base(int number)
{
    /* FIXME: handle negative numbers */

    int reversed_digits = 0,
        remaining_digits = number;

    /* NOTE: The loop will stop when the digit in the middle is reached.  */
    while (reversed_digits < remaining_digits)
    {
        int digit = get_last_octal_digit(remaining_digits);
        reversed_digits = append_octal_digit(reversed_digits, digit);
        remaining_digits = remove_last_octal_digit(remaining_digits);
    }

    /* NOTE: For an odd number of digits, reversed_digits contains
             an extra digit (coming from the middle). */
    return (reversed_digits == remaining_digits)
        || (remove_last_octal_digit(reversed_digits) == remaining_digits);
}

After these steps, I realized the need for a Makefile so I could extract reusable code to new compilation units (in addition, I created some quick and dirty unit tests which you can find at GitHub):

lib/primes.h:

#ifndef _PRIMES_H
#define _PRIMES_H

int is_prime(int number);

#endif

lib/primes.c:

#include "primes.h"

static int find_smallest_divisor_greater_than_one(int number);

int
is_prime(int number)
{
    /* FIXME: handle 0 and 1 */
    return find_smallest_divisor_greater_than_one(number) == number;
}

static int is_divisable(int dividend, int divisor);

static int
find_smallest_divisor_greater_than_one(int number)
{
    /* FIXME: handle negative numbers */

    int smallest_divisor = 2;

    while (!is_divisable(number, smallest_divisor))
    {
        ++smallest_divisor;
    }

    return smallest_divisor;
}

static int
is_divisable(int dividend, int divisor)
{
    /* FIXME: handle division by zero */
    return 0 == dividend % divisor;
}

lib/palindromes.h:

#ifndef _PALINDROMES_H
#define _PALINDROMES_H

int is_palindromic_in_octal_base(int number);

#endif

lib/palindromes.c:

#include "palindromes.h"

static int get_last_octal_digit(int number);
static int append_octal_digit(int number, int digit);
static int remove_last_octal_digit(int number);

int
is_palindromic_in_octal_base(int number)
{
    /* FIXME: handle negative numbers */

    int reversed_digits = 0,
        remaining_digits = number;

    /* NOTE: The loop will stop when the digit in the middle is reached.  */
    while (reversed_digits < remaining_digits)
    {
        int digit = get_last_octal_digit(remaining_digits);
        reversed_digits = append_octal_digit(reversed_digits, digit);
        remaining_digits = remove_last_octal_digit(remaining_digits);
    }

    /* NOTE: For an odd number of digits, reversed_digits contains
             an extra digit (coming from the middle). */
    return (reversed_digits == remaining_digits)
        || (remove_last_octal_digit(reversed_digits) == remaining_digits);
}

static int
get_last_octal_digit(int number)
{
    return number % 8;
}

static int
append_octal_digit(int number, int digit)
{
    /* FIXME: handle invalid digits */
    return number * 8 + digit;
}

static int
remove_last_octal_digit(int number)
{
    return number / 8;
}

Reviewing primes.c, it’s obvious it could perform better, but premature optimization is the root of all evil, so let’s just add a comment for now:

static int
find_smallest_divisor_greater_than_one(int number)
{
    /* FIXME: handle negative numbers */

    /* OPTIMIZATION FIXME: The smallest divisor is always less than
                           the square root of the number. */

    int smallest_divisor = 2;

    while (!is_divisable(number, smallest_divisor))
    {
        ++smallest_divisor;
    }

    return smallest_divisor;
}

The most interesting part of the refactoring process ends here.

After the above, I removed all the FIXME comments one by one. Some of them were bad idea, others got converted to unit tests. All of them were easy to fix by adding some parameter checks to various functions.

Next I generalized palindromes.c to work with other bases than octal, then I created a function named find_octal_palindromic_prime_bigger_than(int number), so I could write this:

void
print_first_150_octal_palindromic_primes()
{
    int n = 0, i;
    for (i = 0; i != 150; ++i)
    {
        n = find_octal_palindromic_prime_bigger_than(n);
        print_octal(n);
    }
}

Of course, main() is pretty understandable now:

int main(int argc, char* argv[])
{
    print_first_150_octal_palindromic_primes();
    return 0;
}

The details are not very entertaining, though you can find individual commits at GitHub.

Performance

I changed both the refactored and the original version to print all the numbers 10 times. Here are the results (ran on my eeePC, compiled to 64 bit with GCC using -O3):

Obfuscated version:

real    0m15.230s
user    0m15.180s
sys     0m0.010s


Clean version:

real    0m15.401s
user    0m15.130s
sys     0m0.040s

The clean version is slightly slower than the original. Sad. But luckily we have a couple of unit tests so we can change the way calculations are done anytime we want, and we already have a good guess on what can be slow: testing each and every number as divisor in primes.c!

After rewriting is_prime() to test only odd numbers and to stop when reaching the square root of the given number, the refactored version gets nearly 14 times faster than the original! The results for 40 iterations of 150 numbers on the same machine:

Obfuscated version:

real    0m59.723s
user    0m59.610s
sys     0m0.000s


Clean version:

real    0m4.432s
user    0m4.410s
sys     0m0.000s

Maybe it could be improved further if it didn’t test numbers whether they are palindromic or not, but it generated palindromic numbers at the first place instead.

How much information did the cleanup give?

I mean literally.

That’s the question I wanted to answer when I began writing this post. Lucky we have some mathematical theory to apply here: entropy, ie. the expected value of information (measured in bits). Though Shannon’s entropy could easily be calculated for these files, I’ll be happy with an approximation. By compressing the complete source code (including unit tests but excluding the textfile containing expected output and performance tests) and looking at compressed sizes, theoretical entropy can be approximated well enough. I will compress the source code from four stages: the original, the structure recovered, the function extracted and the final version:

Original makarios.c (commit 0b966486f8)

main(n,i,a,m){while(i=++n)
for(a=0;a<i?a=a*8+i%8,i/=8,m=a==i|a/8==i,1:(n-++m||printf("%o\n",n))&&n%m;);}

Somewhat readable makarios.c (commit bcf7f4046b)

#include <stdio.h>

#define STOP_AT 522233

int main(int argc, char* argv[])
{
    int n;

    for (n = 2; n <= STOP_AT; ++n)
    {
        int a = 0,
            i = n,
            m;

        while (a < i)
        {
            a = a*8 + i%8;
            i /= 8;
        }

        if (!((a == i) || (a/8 == i)))
            continue;

        m = 2;
        while (0 != n%m)
        {
            ++m;
        }

        if (m == n)
            printf("%o\n", n);
    }

    return 0;
}

Function extracted makarios.c (commit 18b94d3210)

#include <stdio.h>

#define STOP_AT 522233

static int is_palindromic_in_octal_base(int number);
static int is_prime(int number);
static void print_octal(int number);

int main(int argc, char* argv[])
{
    int n;

    for (n = 2; n <= STOP_AT; ++n)
    {
        if (is_palindromic_in_octal_base(n) && is_prime(n))
            print_octal(n);
    }

    return 0;
}

static int get_last_octal_digit(int number);
static int append_octal_digit(int number, int digit);
static int remove_last_octal_digit(int number);

static int
is_palindromic_in_octal_base(int number)
{
    /* FIXME: handle negative numbers */

    int reversed_digits = 0,
        remaining_digits = number;

    /* NOTE: The loop will stop when the digit in the middle is reached.  */
    while (reversed_digits < remaining_digits)
    {
        int digit = get_last_octal_digit(remaining_digits);
        reversed_digits = append_octal_digit(reversed_digits, digit);
        remaining_digits = remove_last_octal_digit(remaining_digits);
    }

    /* NOTE: For an odd number of digits, reversed_digits contains
             an extra digit (coming from the middle). */
    return (reversed_digits == remaining_digits)
        || (remove_last_octal_digit(reversed_digits) == remaining_digits);
}

static int
get_last_octal_digit(int number)
{
    return number % 8;
}

static int
append_octal_digit(int number, int digit)
{
    /* FIXME: handle invalid digits */
    return number * 8 + digit;
}

static int
remove_last_octal_digit(int number)
{
    return number / 8;
}

static int find_smallest_divisor_greater_than_one(int number);

static int
is_prime(int number)
{
    /* FIXME: handle 0 and 1 */
    return find_smallest_divisor_greater_than_one(number) == number;
}

static int is_divisable(int dividend, int divisor);

static int
find_smallest_divisor_greater_than_one(int number)
{
    /* FIXME: handle negative numbers */

    int smallest_divisor = 2;

    while (!is_divisable(number, smallest_divisor))
    {
        ++smallest_divisor;
    }

    return smallest_divisor;
}

static int
is_divisable(int dividend, int divisor)
{
    /* FIXME: handle division by zero */
    return 0 == dividend % divisor;
}

static void
print_octal(int number)
{
    printf("%o\n", number);
}

Modularized version tarball (commit c6c01681e3)

lib/octal_palindromic_primes.c
lib/octal_palindromic_primes.h
lib/palindromes.c
lib/palindromes.h
lib/primes.c
lib/primes.h
makarios.c
Makefile
tests/test.h
tests/test_octal_palindromic_primes.c
tests/test_palindromes.c
tests/test_primes.c

The amount of information in the source code from each stages:

  • Original: 128 bytes (note that the uncompressed C source is smaller, 105 bytes!)
  • After recovering structure: 265 bytes
  • After extracting functions: 689 bytes
  • After organizing into modules with unit tests: 2872 bytes

To summarize: the “compressed” version of the original code contains more information (the gzip header I guess) than the uncompressed file. That’s how you rule at IOCCC! Adding indentation and using the appropriate control structure for each task doubles the information in the code. Extracting some well named functions, adding some comments and naming variables well introduced 2.6 times more information into the source (6.5 times the original 105 bytes), and organizing everything into standalone units with standalone tests multiplied that amount by another 4.1. (That’s 27.3 times more than the original 105 bytes!)

How much work?

According to commit logs, I made visible progress during the following time intervals:

  • Nov 23 18:50:43 2011 – Nov 23 20:54:56 2011: ~2 hours
  • Nov 23 22:56:29 2011 – Nov 24 01:01:11 2011: ~2 hours (with some breaks)
  • Nov 24 23:04:42 2011 – Nov 25 02:09:22 2011: ~3 hours (with many breaks)
  • Nov 26 21:26:47 2011 – Nov 26 23:21:41 2011: ~2 hours

That’s 9 hours of work which includes writing more detailed commit messages than I usually do, taking notes for this blog post, and committing changes way more frequently than I usually do. Also consider that I’m not an experienced C developer, and to make that even worse, most of the work was done in the night, after getting home from real-life work.

Conclusion

I’m not going to suggest anything, since this was just a funny experiment and what’s more, I don’t even think this coding style matches with the C world. The numbers are interesting though.

As an advice, I can say only one thing: when you’re writing code, please think for a moment how long it will take others to understand it. If your code is not crystal clear just by reading through it (without the need for stopping to think for a millisecond, without scrolling back and forth taking notes etc.), then everytime others look at that code, you’re spending your co-worker’s time (thus your company’s money) on something you could’ve got for a one time prize, or even for free if you’d took that three seconds to extract that loop into a separate function or name that variable something better than a and m

Test-driving a regular expression

Sunday, October 23, 2011 @ 01:10 AM Author: athos

“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.