Comments on: How Maatkit benefits from test-driven development

By: Stefano F.

Stefano F. — Tue, 19 Aug 2008 14:01:53 +0000

Practicing me too and it feels great.

It’s not always a bed of roses, though. Testing sometimes requires you to put up more infrastructure. For instance, testing code that manipulates a db or generates xml may not be trivial.

If you have not clear ideas on what you want to do and how, well, could be better to you to think more about it before start or give up tests for a while (and maybe catchup later), because tests are more code do mantain and to change. While when you refactor some internal detail tests are of great help, when refactoring an API tests add a lot more work. (not to say they are not worth the more work required in such cases)

By: david

david — Tue, 19 Aug 2008 05:36:43 +0000

To me writing code is an iterative and incremental process. You have this basic idea of what your class is supposed to do. In the first step, you give it a name, which is supposed to denote the concept of your class. Maybe you also add some javadocs to explain your brainchild. At this point you probably don't have any methods yet. You don't really know in detail how your class is going to work. It's almost a paradox: you need test cases and it's sounds reasonable to write them before your implementation, because then they actually exist and you cannot forget about them. At the same time it doesn't make sense to test something, which doesn't exist yet or you only have a rough idea of how it's actually going to look like.

By: Gregory Haase

Gregory Haase — Mon, 18 Aug 2008 15:58:42 +0000

Congrats on your hole-in-one!

One of the benefits of test-driven development is that it gets you to think about the end result in advance. That often gets me thinking more clearly about all the moving parts of the code that have to change. I also find that putting a fail and a pass test on each conditional in the code can make debugging a lot more straightforward.

It’s tough to see the benefits of unit testing until you experience them first hand. The first time that someone changes a seemingly innocuous line in one of your procedures and subsequently breaks 3 or 4 unit tests you’ll become an instant believer.

When doing work in Oracle databases, I often use utPLSQL to build unit tests for stored procedures and functions. In a good environment, tools like this are worked into a regular build process so that regressions or new issues are caught and reported automatically.

Unfortunately, the limited exception handling that is available in MySQL’s stored procedures and functions makes this kind of testing difficult. I still need to find/build a suitable framework for this.