tony arkles blog

In the lasttwo posts, I talked about the philosophy of testing, and showed the basic framework that Python provides.

The Triangle Example

This example is a classic from Glenford Myers’ The Art of Software Testing, first published in 1979. For all of the advances we’ve seen since then, it’s still a fantastic example of the things that can cause problems in software.

Given the integer lengths of the three sides of a triangle, determine whether the triangle is scalene, isoceles, or equilateral.

You can see that the test is failing because the result is coming back as ‘equilateral’, but we’re asserting that it’s equal to None. I do this while I’m writing my tests to ensure that I’m actually computing the value I’m expecting.

Changing the assert statement corrects the test and makes it run successfully:

We’ve Tested Everything! We’re Done!

… not so fast.

There’s still a few problems. The first one I’m going to address is in testIsoceles(). This test is currently only checking one case: when a==b. Lets beef it up a bit, by addressing all three permutations:

Alright! This is the first bug that our test suite has caught! In the classify_triangle routine, we’re not correctly checking all three cases where we might have an isoceles triangle. Here’s the corrected method:

There’s a number of ways to address this in the original function, but I’d like to modify it so that it matches the description above (that is, sorting so that a ≤ b ≤ c, and performing the computation):

You’ve got a typo in the ‘notvalid’ triangle test. The html code for gt should be the symbol.

I like this series. It’s stepping through the process clearly.

My only criticism, and it’s one I don’t know how to address, is that some people find math examples hard to comprehend. I think that’s because computer people pick them because they believe the example has a strong shared truth value. So, they don’t have to spend as much time explaining or setting up the example. Plus, non-math examples, you might just argue over what it means, or is it true.

But, I think this false, code, test, fix cycle is especially valuable in problem spaces where there isn’t a strong shared understanding because it gives you the chance to learn about both the problem and the solution in little steps.