First, by using TDD (thus writing the tests first) you make sure that your code remains in a testable state all the time (even if you don’t write all the tests to cover all the edge cases) – As anybody working with legacy code can attest, adding unit tests to an existing code base is usually excruciatingly hard and takes a lot of time. It can be done – witness Working with Legacy Code, sure, but it’s a very long and thorny journey. You don’t want to go down this road with the new code you’re writing every day.

Second, by using TDD you always have a decent, highly decoupled design – not a perfect or insanely great design, but quite a usable design to go forward. More often than not, it will be a better design than you’re used to.

“Test-Driven Development” is actually “Test-Driven Design”.

One of the questions which came up during Q&A – I’m paraphrasing here – was:

“I tried TDD and was told not to design or think, just to write the tests and the code. The result was a mess”.

Bob Martin’s answer was along these lines:

If you’re a TDD newbie, you need to leave your old rationale of thinking things through upfront behind. So the recommendation is “Don’t think about the design or what’s next”, but to methodically follow the mantra “Write some failing test” – “Write some code just so the test is satisfied” – “Write some failing test” – “Write some code just so the test is satisfied” – …. As your start to grok the rhythm of TDD, you gradually let your design skills in.

I would like to humbly elaborate on this answer. The practice of TDD consists of three simple steps:

• Step 1 – “Red” – Write some failing test
• Step 2 – “Green” – Write some code just so the test is satisfied (implement the simplest thing that could possibly work (not sure who coined the term, probably Ward Cunningham))
• Step 3 – “Refactor” – Remove all duplication from both your production and your test code

Resist your urge to design upfront, to think through algorithmic solutions and alternatives. Just write a failing test. Then, write some code to make the test pass. Don’t write more code. Just the amount of code to make the test pass.

Now, turn to step 3. If you skip it, you will create a mess.

Step 3 is where your design skills are more than welcome. Apply your design skills to ruthlessly eliminate the duplication you created (and you did create some duplication because you did “the simplest thing that could possibly work” in step 2, didn’t you?) – Just keep in mind that you are not supposed to create a design which anticipates future requirement changes, you are supposed to ruthlessly eliminate duplication to create “the simplest design that could possibly work” for your current code base.

So there are a lot of design skills involved in TDD. It’s just that most of the design skills are applied “after the fact”. They are applied after you made the failing test pass.

There’s another place for design skills in TDD. Look at the first step – “Red”. You are supposed to write a failing test. You will probably need to instantiate an object (which, keep in mind, doesn’t exist yet). Or call a function or method (which don’t exist yet, either) on an existing object. You can apply your API design skills right there: What’s the best way to name the class or function? Which parameters do you need? How do you minimize the number of parameters? How do you make it easy for the test (and future users of the class / function) to accomplish the task at hand?

You aren’t convinced yet? You still need more places to apply your superior brain powers? Good news, there’s even more “thinking” involved. In step 1, you are supposed to write a failing test. This requires a lot of thinking:

• What do I test next?
• What’s the next logical step in the evolution of my method / class?
• What are the edge cases I need to test for?
• Which test will small enough in scope that I can cope with the implementation right away?
• Which test will bring me closer to the solution of the task i’m working on?

Conclusion

If you follow TDD and apply your thinking and design skills as described above, you will end up with a testable, highly decoupled design. It’s not a great design yet, but chances are it’ll be a much better and more usable design than the ones you’ve encountered so far.

Addendum

You may wonder why I didn’t mention the long and hard thoughts you need to think in step 2 while writing the code to make the test pass. Two questions for you: You did write some failing test, just enough testing code so the test fails, correct? Then you did the simplest thing that could possibly work to make the test pass, correct? Nothing more? Good. Go figure.

Then, Hayati Ayguen presented his take of a flow implementation in C++ for signal processing. Terse. Brief. Very focussed on a specific use case – Signal processing. Just enough infrastructure to make it work efficiently. A wonderful contrast to the Java implementation – which does have its merits, don’t get me wrong.

A great and thought provoking evening. Thanks to the organizers. I look forward to participate in upcoming meetings.

[Update 3/2/12 - Fixed up an incomplete sentence - Looks like it was way to late Wednesday night (or I got distracted by the late night soccer game analysis on TV ]

• 18:45 – Welcome by Nick Ashley, MD of ThoughtWorks Deutschland
• 19:00 – Wolf Schlegel: “Dos and don’ts of Continuous Integration and Delivery”
• 19.20 – Erik Dörnenburg: “Lean for enterprise architecture
• 19:45 – Martin Fowler: “Software Design in the 21st Century”
• 20:30 – Networking – drinks and food

Unfortunately, I missed about half of Wolf Schlegel’s talk on Continous Delivery, but judging on the second half, I would have preferred more in-depth discussion of technologies and best practices. The talk seemed like a space-station’s eye view of the topic.

Erik Dörnenburg was next talking about Lean Enterprise Architecture. I very much liked his analogy of comparing the role of a Software Architect to that of a Gardener instead of a traditional Architect. Spot on. Quite a few interesting thoughts on how to causing change in an organisation / team, too.

Martin Fowler gave two short talks, on on “Domain Specific Languages” and one on “Nondeterministic Tests“.

I was quite keen on the Domain Specific Language part, as we’re currently moving away from a “home-grown” Domain Specific Language for NC-code templating & output to a Python-based solution as we found that our own language lacked the expressiveness we are looking for. My key take-away was that there are two ways to create a DSL, external & internal and that we’re migrating from an external DSL to an internal DSL. Looks like the DSL book is supposed to be on my reading list real soon now.

Martin’s thoughts on “Nondeterministic Tests” were especially interesting as I was attending a talk on “Unit Testing & Concurrency” right last week in Karlsruhe. Very interesting to see the different takes on the topic – Abstracting away the concurrency altogether for unit testing purposes whereas Martin was leaning towards integration & acceptance testing and giving very sound advice on how to deal with concurrency issues within the tests (polling, callbacks, test doubles).

As you might have imagined, I mostly skipped the Networking part due to my sociophobia.

Overall, a very worthwhile evening and I very much look forward to future Thoughtworks events.

Wie erstellt man Unit Tests für nebenläufige Funktionen? Man testet nicht die Nebenläufigkeit. Man abstrahiert von der Nebenläufigkeit, das heißt man erstellt das System so, daß nebenläufige Funktionen über abstrakte Interfaces beschrieben werden.

Die nachfolgende Diskussion zeigte wieder einmal, daß der Informatiker an sich nicht einer der Flexibelsten oder Lernfähigsten ist (*). Anmerkungen wie: “Damit testen Sie aber nicht die Aspekte X und Y”, “Das ist bei uns so nicht einsetzbar, weil X” oder “Bei uns liegt aber Z vor, daher können wir nicht…” zeigten, das einige Kollegen wieder exakt die Argumente aufwärmten, die sie in den letzten 10 Jahren bereits (erfolglos) gegen die Konzepte beim Unit-Testing von Benutzerschnittstellen, Datenbankzugriffen, Netzwerkdiensten und anderem vorgebracht hatten:

Wie erstellt man Unit Tests für Benutzerschnittstellen?

Man testet nicht die Benutzerschnittstelle. Man abstrahiert von der eigentlichen Benutzerschnittstelle, indem man beispielsweise MVP (Model View Presenter) nutzt.

Wie erstellt man Unit Tests für die Datenbank?

Man testet nicht die Datenbank. Man abstrahiert von den eigentlichen Datenbankzugriffen, indem man diese in eine eigene, möglichst einfache Mapping-Schicht auslagert.

Wie erstellt man Unit Tests für Netzwerkdienste?

Man testet nicht die Netzwerkdienste. Man abstrahiert von den Netzwerkdiensten, indem man diese durch abstrakte Interfaces beschreibt.

Um zwei weitere Beispiele aus der täglichen Praxis der extragroup GmbH zu bringen:

Wie erstellt man Unit Tests für das Erstellen von Objekten in einem CAD-System?

Man testet nicht das Erstellen der Objekte. Man abstrahiert vom Erstellen der CAD-Objekte, indem das eigentliche Erstellen der CAD-Objekte in eine möglichst einfache Klasse auslagert – die man im schlimmsten Falle über ein abstraktes Interface beschreibt.

Wie erstellt man Unit Tests für das Erstellen von Werkzeugen in einem CAD-System?

Man testet nicht das Verhalten der Werkzeuge. Man abstrahiert vom den CAD-Werkzeugen, indem die eigentliche Schnittstelle zum API des CAD-System durch ein abstraktes Interface beschreibt.

Der geneigte Leser wird sicher inzwischen ein Muster erkannt haben.

Die entscheidende Erkenntnis (für uns wie für die oben genannten Kollegen) ist, daß all dies nur mit testgetriebener Entwicklung sauber möglich ist. Unit Tests nachträglich zu einem System hinzuzufügen, welches nicht auf solche Tests ausgelegt ist, erweist sich in der Praxis als enorm aufwendig.

(*) Ich zähle mich selbstverständlich auch zu genau dieser Gruppe, die neuen Ideen mit einem gezielten “Das funktioniert nicht, weil….” begegnet.

Apple Computer announced that it had acquired NeXT, Inc. for about $400M.

January 1997

We had been working our asses off for about 3 years to get our OpenDoc-based database components to a usable and sellable state. Together with a band of other OpenDoc developers, we intended to make a big splash at MacWorld 1997, San Francisco. And a reasonable splash we made. Customer were excited about our products, other developers were excited about interfacing to our components and international Distributors were lining up to localize & sell our components.

Members of the Apple Enterprise Sales team (yup, back then there was such a thing) had been arranging a meeting at NeXT headquarters with a couple of NeXT engineers for us to promote our components and to get a feeling for where thing are heading. I do vividly remember sitting in a conference room in Redwood city with several NeXT engineers, among them a rather young opinionated guy named Scott Forstall, and the NeXT engineers basically dismissing the idea of loosely coupled, componentized software.

March 1997

On March, 14th, Apple Computer was putting OpenDoc into maintenance mode – which was the marketing weasels way of saying that the platform our product was based on was dead in the water. We were devastated – For three years, we had been pouring our heart, soul and last, but not least, a lot of our personal money into the product and it was dead.

CeBIT, the world largest computer fair, was upon us and, despite Apple’s announcement about OpenDoc’s demise, we were scheduled to show our OpenDoc components at the Apple booth in Hannover. We didn’t go.

Mark B. Johnson, a fine man and head of European developer relations back then, called us and expressed his hope that, despite the OpenDoc debacle, we would support the Apple platform going forward. He offered us WWDC tickets so we could talk to Apple engineers and get a glimpse on where Apple was heading in the future.

May 1997

WWDC was in San Jose Convention Center back then. I do remember sitting in the main hall next to @BradHutchings during Friday’s Q&A session. I’m not 100% sure, but I think it was Brad who was asking the infamous question “What about OpenDoc?” at the very beginning of the Q&A session (about 4:30min into the video).

It wasn’t fun. Steve’s answer was frank, to the point and, in hindsight, spot on – but see for yourself:

Rest in peace, Steve. I’ve learned an awful lot from you over the years.

And now I’m off pre-ordering an iPhone 4S for both me & my oldest daughter.

What’s the simplest way to start? If the user doesn’t click on a polygon object, our tool should ignore the clicks. How does RedGreenLineTool know if the clicks happen on a polygon object? For know, we let it know by calling MouseOverPolygonObject() before adding tool points. Sounds reasonable.

TEST_N(ToolPointsShouldBeReflectedAsStartEndPointOfLineObject)
{
	MockRedGreenLineTool vwTool;
	vwTool.MouseOverPolygonObject();

	vwTool.AddPoint(WorldPt3(0, 0, 0));
	vwTool.AddPoint(WorldPt3(50, 0, 0));

	CHECK_EQUAL(2, vwTool.GetNumToolPoints());
}

If we don’t call MouseOverPolygonObject() before adding points, they shouldn’t be added to the list of points tracked.

TEST_N(ToolPointNotOnPolygonShouldBeIgnored)
{
	MockRedGreenLineTool vwTool;

	vwTool.AddPoint(WorldPt3(0, 0, 0));
	vwTool.AddPoint(WorldPt3(50, 0, 0));

	CHECK_EQUAL(0, vwTool.GetNumToolPoints());
}

Implementation, of course, is rather trivial (for now . We just add a bool fMockMouseOverPolygonObject to MockRedGreenLineTool, set it MouseOverPolygonObject(), test it in AddPoint() and we’re done.

Well, not really. We do have an implementation for MockRedGreenLineTool only, we need to move the implementation up the inheritance tree to RedGreenLineTool to turn it into something useful.

class RedGreenLineTool {

	virtual bool IsMouseOverPolygonObject() = 0;

	void AddPoint(const WorldPt3& p) {
		if (IsMouseOverPolygonObject())
			fToolPoints.PushData(p);
	}
};

Implementation of IsMouseOverPolygonObject() is rather trivial for MockRedGreenLineTool, we just return fMockMouseOverPolygonObject. Of course, VectorworksRedGreenLineTool needs a more sophisticated implementation, but (as intended) a rather simple one:

class VectorworksRedGreenLineTool {

	virtual bool IsMouseOverPolygonObject() {
		MCObjectHandle overObject = NULL;
		short overPart;
		long code;
		gSDK->TrackTool(overObject, overPart, code);

		return (overObject && ! VWPolygon2DObj::IsPolygon2DObject(overObject));
	}
};

Now this rather straightforward implementation doesn’t quite work yet, as this code doesn’t reflect the state Vectorworks is in. every mouse click is registered by Vectorworks first, then an event is sent to the tool to process it. If we choose to ignore the mouse click, we need to notify Vectorworks of this fact. Thus, we need to make some minor changes to the code to accommodate for this behavior.

class RedGreenLineTool {

	virtual void PopLastToolPoint() = 0;

	void AddPoint(const WorldPt3& p) {
		if (IsMouseOverPolygonObject())
			fToolPoints.PushData(p);
		else
			PopLastToolPoint();
	}
};

While MockRedGreenLineTool gets away with an empty implementation for PopLastToolPoint(), VectorworksRedGreenLineTool needs to notify Vectorworks that the last tool point registered should be removed:

class VectorworksRedGreenLineTool {

	virtual void PopLastToolPoint() {
		gSDK->PopLastToolPt();
	}
};

Where are we at? We do have a basic implementation of mouse tracking in place. RedGreenLineTool is able to tell if the mouse is over a polygon object while the mouse is clicked. In the next episode, we will tackle tracking mouse clicks on a single or two different polygons in order to create red or green lines.

Previous Episode

TEST_N(ToolPointsShouldBeReflectedAsStartEndPointOfLineObject)
{
	MockRedGreenLineTool vwTool;

	vwTool.AddPoint(WorldPt3(0, 0, 0));
	vwTool.AddPoint(WorldPt3(50, 0, 0));

	MockRedGreenLineObject* vwObject = vwTool.Create();

	CHECK_EQUAL(WorldPt3(0, 0, 0), vwObject->GetStartPoint());
	CHECK_EQUAL(WorldPt3(50, 0, 0), vwObject->GetEndPoint());

	delete vwObject;
}

We expect that the tool object will be able to create the line object for us and that the tool will take care of making sure that the start & end point of the line object will reflect the tool points.

In order to get the test to compile, we need to implement Create() for MockRedGreenLineTool.

class MockRedGreenLineTool : public RedGreenLineTool {

public:

	MockRedGreenLineObject* Create() const {
		MockRedGreenLineObject* lineObject = new MockRedGreenLineObject();

		lineObject->SetStartPoint(fToolPoints[0].fPoint);
		lineObject->SetEndPoint(fToolPoints[1].fPoint);

		return lineObject;
	}		

};

Now we need to come up with a simple implementation for MockRedGreenLineObject. Not a lot to see here – just a mock implementation.

class MockRedGreenLineObject {

public:

	void SetStartPoint(const WorldPt3& p) {
		fStartPoint = p;
	}

	void SetEndPoint(const WorldPt3& p) {
		fEndPoint = p;
	}

	virtual WorldPt3 GetStartPoint() const {
		return fStartPoint;
	}

	virtual WorldPt3 GetEndPoint() const {
		return fEndPoint;
	}

private:

	WorldPt3 fStartPoint;
	WorldPt3 fEndPoint;
};

Now the code compiles, links and the test passes. As in episode 1, the code is stuck in the “Mock” classes, but we need to drive it from Vectorworks. Let’s refactor us out of this mess.

First, we push the implementation of Create() up to the base class, RedGreenLineTool. However, RedGreenLineTool::Create() shouldn’t return an instance of MockRedGreenLineObject, but an instance of a more generic RedGreenLineObject class in order to accommodate creation of a Vectorworks-specific subclass. Creation of the particular instance is left to the subclasses of RedGreenLineTool.

We move the code from MockRedGreenLineObject to a new superclass RedGreenLineObject.

class RedGreenLineObject {

public:

	void SetStartPoint(const WorldPt3& p) {
		fStartPoint = p;
	}

	void SetEndPoint(const WorldPt3& p) {
		fEndPoint = p;
	}

	virtual WorldPt3 GetStartPoint() const {
		return fStartPoint;
	}

	virtual WorldPt3 GetEndPoint() const {
		return fEndPoint;
	}

private:

	WorldPt3 fStartPoint;
	WorldPt3 fEndPoint;
};

Code still compiles, links and passes the tests. Now for the surgery concerning RedGreenLineTool::Create():

class VectorworksRedGreenLineTool : public RedGreenLineTool {

	RedGreenLineObject* CreateRedGreenLineObject() const {
		return VectorworksRedGreenLineObject();
	}
};

class MockRedGreenLineTool : public RedGreenLineTool {

	RedGreenLineObject* CreateRedGreenLineObject() const {
		return MockRedGreenLineObject();
	}
};

class RedGreenLineTool {

public:

	RedGreenLineObject* CreateRedGreenLineObject() const = 0;

	RedGreenLineObject* Create() const {
		RedGreenLineObject* lineObject = CreateRedGreenLineObject();

		lineObject->SetStartPoint(fToolPoints[0].fPoint);
		lineObject->SetEndPoint(fToolPoints[1].fPoint);

		return lineObject;
	}		

};

Again, code compiles, links and our tests pass. What’s left? We need to hook up the classes to CTool_EventSink and create the Vectorworks geometry.

long CTool_EventSink::LegacyMain(long action, long message1, long message2)
{
	long result = 0;

	switch (action) {

		case kToolHandleComplete:
			fRedGreenLineTool->Create();
			break;
	}
};

Compiles, links. No surprises here. We start Vectorworks, select our tool, click twice to create a line – but nothing happens….yet. Ah, we forgot to create the geometry. How to do that? Here’s the simplest way of doing it which comes to my mind:

class RedGreenLineTool {

public:

	RedGreenLineObject* Create() const {
		RedGreenLineObject* lineObject = CreateRedGreenLineObject();

		lineObject->SetStartPoint(fToolPoints[0].fPoint);
		lineObject->SetEndPoint(fToolPoints[1].fPoint);

		lineObject->CreateGeometry();

		return lineObject;
	}		

};

Of course, the implementation of CreateGeometry() in MockRedGreenLineObject will be empty, whereas VectorworksRedGreenLineObject::CreateGeometry() is somewhat beefier:

class VectorworksRedGreenLineObject {

	virtual void CreateGeometry() {
		VWLine2DObj line(fStartPoint.x, fStartPoint.y, fEndPoint.x, fEndPoint.y);
		line.AddObjectToContainer(gSDK->GetDefaultContainer());
	}

};

We can easily deal with the non-testability of CreateGeometry(), as all the logic of the line object’s “model” itself is under test. And if something goes horribly wrong in CreateGeometry(), it should be easy to figure out.

RedGreenLineObject doesn’t feature an awful lot of sophisticated logic so far, but we are not done yet. The “spec” calls for creating a red or green line depending on where the user sets the clicks. Sounds like this attribute will find a good home in the RedGreenLineObject class. Speaking of it, determining the location of the clicks test first sounds like an interesting challenge. Let’s try to tackle that one in the next episode.

Previous Episode | Next Episode

Using the MockRedGreenLineTool from within a CTool_EventSink doesn’t sound quite right. After all it’s supposed to be a mock implementation. We need to use a real tool implementation in the CTool_EventSink. Let’s do some restructuring to accomplish that. First, create a new class RedGreenLineTool with the code from MockRedGreenLineTool.

class RedGreenLineTool {

public:

	virtual ~RedGreenLineTool() {
	}

 	void AddPoint(const WorldPt3& p) {
		fToolPoints.PushData(p);
	}	

	virtual void PopPoint() {
		fToolPoints.PopData();
	}

	short GetNumToolPoints() const {
		return fToolPoints.NumItems();
	}

	TSmallArray<WorldPt3> fToolPoints;

};

Now, make MockRedGreenLineTool a subclass of RedGreenLineTool:

class MockRedGreenLineTool : public RedGreenLineTool {
}

and create VectorworksRedGreenLineTool, which is also a subclass of RedGreenLineTool.

class VectorworksRedGreenLineTool : public RedGreenLineTool {
}

This sure looks better to our TDD newbie eye. We have a common implementation for both the MockRedGreenLineTool used for testing and a VectorworksRedGreenLineTool used to connect the code to Vectorworks. Running the tests shows we didn’t break anything. Now we are able to use VectorworksRedGreenLineTool in a VWToolDefaultLine_EventSink implementation:

long CTool_EventSink::LegacyMain(long action, long message1, long message2)
{
	long result = 0;

	switch (action) {

		case kToolDoSetup:
			result = VWToolDefaultLine_EventSink::LegacyMain(action, message1, message2);

			fRedGreenLineTool = new VectorworksRedGreenLineTool();
			break;

		case kToolDoSetDown:
			result = VWToolDefaultLine_EventSink::LegacyMain(action, message1, message2);

			if (fRedGreenLineTool)
				delete fRedGreenLineTool;
			fRedGreenLineTool = NULL;
			break;

		case kToolPointAdded: {

			WorldPt3 toolPoint;
			if (gSDK->GetToolPt3D(gSDK->GetNumToolPts() - 1, toolPoint))
				fRedGreenLineTool->AddPoint(toolPoint);
			break;
		}

		case kToolPointRemoved:
			fRedGreenLineTool->PopPoint();
			break;

		default:
			result = VWToolDefaultLine_EventSink::LegacyMain(action, message1, message2);
			break;

	}

	return result;
}

Using the debugger, we are able to verify that everything is working out as expected.

Not a lot of functional but structural code changes in this episode, but we ended up with a class hierarchy which hints at things to come. We expect to push code common between the mock and Vectorworks implementation of the tool up the class hierarchy and code specific to the mock or Vectorworks implementation of the tool in the subclasses.

Let’s see how this class hierarchy holds up in the next episode when we tackle creating a line – test first, of course.

Previous Episode | Next Episode