Weiqi Gao's Observations - tests tag

What Test Driven Won't Get Me

Tue, 29 Apr 2008 16:27:54 GMT

Thanks to Eric and Brian and other champions of test first development, I've been profitably writing unit tests and functional tests in various projects for more than seven years.

Nowadays I wouldn't dare delivering anything without having thoroughly tested it. For me, the tests serves three purposes:

To ensure that the functionalities are implemented correctly
To discover corner cases that you just couldn't think of during on-paper design
To provide a safety net that is needed to confidently refactor the code base to improve design

However, my own experience with the concept of test driven design has been mixed. And here are some of the limitations of the approach, as I see it:

Your test driven design won't be that much better than your non-test driven design. If you know nothing about designing a compiler, no amount of testing will make you come up with a design for a compiler
Your tests will drive you to designs that are more complicated than necessary, with an abundance of entities and interactions. You will be doing a lot of "create class", "create method", "create field" from the IDEs refactor menu, but rarely do "consolidate classes" or "consolidate methods" because no such refactoring exists
Your test driven design may drive you towards a design that's less amendable for future changes. Without forethought, you may be too focused on delivering functionality that satisfy only the current requirements, thinking "I can always refactor later to accommodate future requirements"

In other words, if you don't know how to design, no amount of testing will make you a good designer.

In other news, Donald Knuth professes that "With the caveat that there’s no reason anybody should care about the opinions of a computer scientist/mathematician like me regarding software development, let me just say that almost everything I’ve ever heard associated with the term "extreme programming" sounds like exactly the wrong way to go...with one exception. The exception is the idea of working in teams and reading each other’s code. That idea is crucial, and it might even mask out all the terrible aspects of extreme programming that alarm me."

Friday Java Challenge: Write A Regular Expression Parser

Fri, 17 Aug 2007 12:41:20 GMT

Instead of a Friday Java Quiz, I'll pose a challenge. And it is not a challenge to your Java skills, but a challenge to the Test-First Design doctrine, which holds that a test-first approach can result in a better or simpler design.

I first witnessed this principle at work at the first No Fluff Just Stuff conference in St. Louis several years ago, where I sat in on Uncle Bob's session on test-first design and followed his "score a bowling game" demonstration.

I have been following a test-driven approach ever since, and I have benefited enormously from this approach: this is true especially in the responsibility allocation among cooperating classes, untangling tightly coupling, and API designs.

However, I have always felt that certain systems can only be designed with enough knowledge about the domain that might not be gained through the mere writing of tests. This is particularly true in areas where non-trivial theories are involved in the solution of a problem. My usual example is "You can't write Math.sin() with a test-first approach."

It seems to me that the test-first design is applicable for trivial problems, but not for complicated problems where the naive solution is the wrong solution.

With that in mind, here's today's Java challenge: Using a test-first approach, and without resorting to any text books, or Google, or looking at the sources of existing regular expression implementations, write a simple regular expression matcher that supports the following features:

c: literal character c
. (period): any single character
^: beginning of input string
$: end of input string
*: zero or more occurrences of the previous character

Refactoring Is Garbage Collection Of The Source

Wed, 21 Sep 2005 03:00:12 GMT

We are doing another round of refactoring in my current project. This is one of those biggish refactorings that changes the code structure for the better. We've done this before (as I blogged 235 days ago.) And here's some of our thoughts on the matter of refactoring, especially big refactoring.

According to Rob, as you code by adding new features and fixing bugs, the tension in the code increases. It is wise to do refactorings from time to time to release the tension so that the code base remains pliable. This is very important for the continued success of the code base.

Big refactorings, as opposed to regular refactorings that you do as you code, is rather like garbage collection (of the mark and sweep kind) in that i) you stop everything else in the code base to do it; ii) the code base will be cleaner afterwards so that you can code more efficiently.

Here's another analogy: If the entire product is a quilt and each individual features are the piece parts, then regular refactoring can be thought of as ironing out the pieces before stitching them onto the quilt and big refactoring can be though of as ironing out the while quilt. Both are necessary. One doesn't imply the other. I'm tempted to call them local refactorings and global refactorings.

Of course, all these refactoring is made possible by the unit tests and functional tests that we have written. We are not yet "test first" on this project, but we spend quite a lot of time (almost 1:1) writing tests.

Writing tests is such a natural part of the project that time for writing tests are part of the estimates for each feature: "4 hours to write the code, 4 hours to write the tests." Tests are not skimmed even when we are up against a deadline:

Jonathan: I can finished the code before COB today. Do you want me to check in the code?

Kevin: You want to check in broken code?

Jonathan: They aren't broken.

Kevin: Prove it!

Jonathan: (Lost for words. ...) I can write the tests later.

Rob: Write the tests now.

We♥Tests