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

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

We will be using a slightly modified version of CppUnitLite2, for more details on how the testing targets are integrated in the Xcode projects please refer to Episode 0 of the plug-in object series.

As in our plug-in object series, the first challenge is “How do we start”?

As our tool will require two clicks, we may get away with subclassing VWToolDefaultLine_EventSink to implement the interactive behavior of the tool. Of course, we won’t be able to use a VWToolDefaultLine_EventSink in our testing target, as the testing environment runs as a separate application. So we need to come up with our own “Vectorworks tool” class. Let’s do that and see were it leads us.

What to test first? Our tool will be collecting up to two clicks (“tool points” in Vectorworks SDK lingo). Upon initialization, there are no tool point in the collection:

#include "CppUnitLite2.h"

TEST_N(ToolObjectShouldHaveNoPointsUponInitialization)
{
	MockRedGreenLineTool vwTool;

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

Not an awful lot of sophistication here, but we sure know how to make this test pass (doing the simplest thing that could possibly work):

class MockRedGreenLineTool {

public:

	short GetNumToolPoints() const {
		return 0;
	}

};

Compiles, links and even passes the test. Excellent. We’re off to a great start. Now for some more, ahm, sophistication. The tool should store the tool points (to create the line later on – we have no clue yet how to do that in a test-first fashion, but let’s just follow our chosen path of rather trivial steps for a while):

#include "CppUnitLite2.h"

TEST_N(ToolObjectShouldRememberToolPoints)
{
	MockRedGreenLineTool vwTool;

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

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

Making this test pass is no challenge either (even for a small mind like me):

class MockRedGreenLineTool {

public:

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

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

	TSmallArray<WorldPt3> fToolPoints;

};

Now that we’re on a roll, let’s add one more “event” to our class, removing tool points. Users will be able to back out of a Vectorworks tool step by step by removing the last tool point added.

TEST_N(ToolObjectPoppingToolPoints)
{
	MockRedGreenLineTool vwTool;

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

	CHECK_EQUAL(2, vwTool.GetNumToolPoints());

	vwTool.PopPoint();

	CHECK_EQUAL(1, vwTool.GetNumToolPoints());

	vwTool.PopPoint();

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

Luckily, TSmallArray features a method to remove the last entry added, so making the test pass is straightforward:

class MockRedGreenLineTool {

public:

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

	// ...

};

Where are we at? We now have a tool class collecting tool points (with the added bonus of being able to remove those tool points later). There are three questions which come to our mind:

• We need to somehow connect MockRedGreenLineTool to the VWToolDefaultLine_EventSink
• MockRedGreenLineTool needs to be able to know about the clicks being on a polygon
• MockRedGreenLineTool needs to create a “red or green line object”

Let’s try to tackle connecting MockRedGreenLineTool to VWToolDefaultLine_EventSink in the next episode.

Previous Episode | Next Episode

A Vectorworks tool is a more sophisticated problem for a small mind like yours truly: It interacts with the drawing in a series of clicks, objects may be tracked while tool is running etc. How do we capture this potentially rich interaction test-first? Before we tackle these questions, let’s describe the tool, code named “Red/Green Line Tool”:

As the name implies, it will collect two clicks in the document and draw a green line if the start- and endpoint of the line (the first & second “click”) are are on a 2D polygon. If the clicks aren’t on a 2D polygon, they should be ignored. To top things off, a red line should be drawn if the startpoint is located on a different 2D-polygon than the endpoint:

My goal is neither to cover all bases with the tests (I intend to leave those as an exercise for the reader nor to develop a shippable, fully Vectorworks-conform tool (my day job takes care of this desire), but to focus on these three questions:

• How do I isolate the “interactiveness” of the tool in a testable class?

• How do I isolate & test the creation of Vectorworks geometry?
• How do the chosen tests drive the design & architecture of the code?

Tune in next week when you’ll hear Dr. Bob wondering about how to get this thing off the ground.

Episodes so far:

• Episode 0 – Introduction
• Episode 1 – Starting
• Episode 2 – Structural changes
• Episode 3 – Creating Geometry
• Episode 4 – Tracking mouse movement

Please download the Xcode 3.2.3 project including all the sources here – SimpleCabinet.zip. The folder SimpleCabinet should be dropped into Vectorworks 2011 SDK’s Sources folder, like this:

The project features two targets, a testing target named “CppUnitLite2″ and the plug-in module shared library target, which outputs to /Applications/Vectorworks2011/Plug-ins. You will notice that all classes plus tests are contain in ExtObject.cpp. I’m doing this for small spikes like this – in real life, I would put each class in a separate file, no code in the header file etc.

The code features additional tests, refactorings and more usage of VWFC in SimpleCabinetCreator.

I haven’t gotten around to preparing & cleaning up the Visual Studio project of the Simple Cabinet project. Make sure to bug me so I feel obliged to release it, too.

Summary

It’s possible to create VectorWorks plug-in objects via TDD. In fact, it’s desirable: Developing the code test-first gave us a very nice separation between the testable model and a very thin layer creating the actual Vectorworks geometry. The SDK stubs (which exist, at this point, for the sole purpose of satisfying the linker) allow us to have a separate testing target and to mix testing code and non-testing code freely.

I found that it’s also possible to develop Vectorworks Layoutmanager-based dialogs (either straight ISDK or VWUI-based) in a strict TDD fashion, but that’s another series of posts waiting to be written and code / project files waiting to be cleaned up.

Wether it’s possible to develop Vectorworks tools in a test-driven fashion remains to be seen (although I’m pretty optimistic that it can be done quite nicely). I do have some thoughts on this matter but they aren’t coherent yet.

If you have any feedback regarding this series, please do not hesitate to post comments on the episodes, or contact me at hm dot kern at extragroup dot de, on Twitter or Facebook. I look forward to hearing from you.

Episodes

• Episode 0 – Introduction
• Episode 1 – How to start?
• Episode 2 – Spicing up our class
• Episode 3 – Not doing the same sketch twice
• Episode 4 – Creating Vectorworks geometry
• Episode 5 – A third class
• Episode 6 – Rolled-up newspaper
• Episode 7 – A few more additions
• Epilogue & Code

TEST_N(FrontModelRightBlindFront)
{
	SimpleCabinetModel simpleCabinet(2 * 200 + 2 * SimpleCabinetModel::kBoardThickness + 50,
									 3 * 150 + 2 * SimpleCabinetModel::kBoardThickness + 70, 800);

	FrontModel frontModel(simpleCabinet.GetFrontModelOrigin(), simpleCabinet.GetFrontWidth(), simpleCabinet.GetFrontHeight());

	CHECK_EQUAL(SimpleCabinetModel::kBoardThickness, frontModel.GetRightZBlindFront());
}

Well, you could see that one coming, making the test pass is rather trivial – but it gets us on the track to more sophisticated functionality.

	WorldCoord GetRightZBlindFront() const {
		return fOrigin.z;
	}

Let’s add another check to the test. The height of the right blind front should be the height of the front model.

	CHECK_EQUAL(3 * 150 + 70, frontModel.GetRightBlindFrontHeight());

Quite obvious and should be easy to implement. There’s already an instance variable fHeight in the FrontModel:

	WorldCoord frontModel.GetRightBlindFrontHeight() const {
		return fHeight;
	}

The third component needed to generate the geometry for the right blind front model is the base rectangular shape for the extrude. Another check for our test.

	CHECK_EQUAL(WorldRect(SimpleCabinetModel::kBoardThickness + frontModel.GetNumColumns() * FrontModel::kSegmentWidth,
						  FrontModel::kSegmentDepth,
						  SimpleCabinetModel::kBoardThickness + simpleCabinet.GetFrontWidth(), 0),
				frontModel.GetRightBlindFrontBase());

Introducing two additional constants for the tile/segment’s width and depth, making the test pass requires a few lines of code:

class FrontModel {

	WorldRect GetRightBlindFrontBase() const {
		WorldCoord xStart = fOrigin.x + GetNumColumns() * kSegmentWidth;
		WorldCoord xEnd = fOrigin.x + fWidth;

		WorldRect r(0, 0, 0, 0);
		if (xStart != xEnd)
			r.Set(xStart, kSegmentDepth, xEnd, 0);

		return r;
	}
};

The top blind front is tackled the same way – We need it’s z position, it’s x dimensions and it’s height. Not an awful lot to see there. Now let’s check if we’re able to generate Vectorworks geometry with this model.

	void CreateFrom(const FrontModel& frontModel) {

		// ...

		WorldRect topBlindFrontBase = frontModel.GetTopBlindFrontBase();
		if (topBlindFrontBase != WorldRect(0, 0, 0, 0)) {
			MCObjectHandle topBlindFront = gSDK->CreateExtrude(frontModel.GetTopZBlindFront(), frontModel.GetTopZBlindFront() + frontModel.GetTopBlindFrontHeight());
			gSDK->AddObjectToContainer(gSDK->CreateRectangle(frontModel.GetTopBlindFrontBase()), topBlindFront);
		}

		WorldRect rightBlindFrontBase = frontModel.GetRightBlindFrontBase();
		if (rightBlindFrontBase != WorldRect(0, 0, 0, 0)) {
			MCObjectHandle rightBlindFront = gSDK->CreateExtrude(frontModel.GetRightZBlindFront(), frontModel.GetRightZBlindFront() + frontModel.GetRightBlindFrontHeight());
			gSDK->AddObjectToContainer(gSDK->CreateRectangle(frontModel.GetRightBlindFrontBase()), rightBlindFront);
		}

In fact, we are:

Tune in next weeks when you hear Dr. Bob say: “Let’s sum it up, post the code and I’m outta here”.

Previous Episode | Next Episode

TEST_N(FrontModelOrigin)
{
	SimpleCabinetModel simpleCabinet(600, 720, 800);

	FrontModel frontModel(simpleCabinet.GetFrontModelOrigin());

	CHECK_EQUAL(WorldPt3(SimpleCabinetModel::kBoardThickness, 0, SimpleCabinetModel::kBoardThickness), frontModel.GetOrigin());
}

Making this test pass requires a series of simple changes to FrontModel.

class FrontModel {

public:

	FrontModel(const WorldPt3& origin) :
		fOrigin(origin) {
	}

	WorldPt3 GetOrigin() const {
		return fOrigin;
	}

private:

	WorldPt3 fOrigin;
}

After making these changes gcc tells us that we should probably fix the tests FrontModelPositionOfFirstSegment and FrontModelPositionOfSecondSegment in order to make this thing compilable again. As in FrontModelOrigin, this requires us to replace WorldPt with WorldPt3 and we’re basically done.

With this out of the way, let’s concentrate on generalizing our FrontModel. So far, we’re able to calculate the position of the first and second segment / tile (assuming both fit into the cabinet). Looking at the screenshot in episode 0, it sure looks like the front tiles should be arranged in rows & columns. Let’s see if we can work towards this. How about computing the number of front tile rows & columns which “fit” into a given cabinet? Let’s start with a simple test – if the cabinet is too small, no front tiles will fit at all.

TEST_N(FrontModelNoRowsNoColumnsNotWideEnough)
{
	SimpleCabinetModel simpleCabinet(150, 720, 800);

	FrontModel frontModel(simpleCabinet.GetFrontModelOrigin(),
						  simpleCabinet.GetFrontWidth(),
						  simpleCabinet.GetFrontHeight());

	CHECK_EQUAL(0, frontModel.GetNumRows());
	CHECK_EQUAL(0, frontModel.GetNumColumns());
}

In order to be able to compute the number of rows & columns, we have to supply the FrontModel with the space available for placing front tiles. So, we need tests to for these functions. Let’s #if 0 the last test for a moment and write new tests for GetFrontWidth() and GetFrontHeight().

TEST_N(SimpleCabinetFrontWidthHeight)
{
	SimpleCabinetModel simpleCabinet(600, 720, 800);

	CHECK_EQUAL(600 - 2 * SimpleCabinetModel::kBoardThickness,
				simpleCabinet.GetFrontWidth());
	CHECK_EQUAL(720 - 2 * SimpleCabinetModel::kBoardThickness,
				simpleCabinet.GetFrontHeight());
}

Let’s make this test pass.

class SimpleCabinetModel {

public:

	WorldCoord GetFrontWidth() const {
		return fWidth - 2 * kBoardThickness;
	}

	WorldCoord GetFrontHeight() const {
		return fHeight - 2 * kBoardThickness;
	}
};

Backtracking to our test FrontModelNoRowsNoColumnsNotWideEnough, we change FrontModel‘s constructor (again).

class FrontModel {

public:

	FrontModel(const WorldPt3& origin, WorldCoord width, WorldCoord height) :
		fOrigin(origin), fWidth(width), fHeight(height) {
	}
};

What was our intital goal? Ah, computing the number of rows & columns (in order to make the test pass). Well, that’s straightforward:

class FrontModel {

public:

	long GetNumRows() const {
		return 0;
	}

	long GetNumColumns() const {
		return 0;
	}
};

Indeed, it’s pretty straightforward for the test we’re trying to make pass. We just write enough code to make the test pass. And returning 0 makes the test pass. Let’s move on to the next test.

TEST_N(FrontModelThreeRowsTwoColumnsFits)
{
	SimpleCabinetModel simpleCabinet(2 * 200 + 2 * SimpleCabinetModel::kBoardThickness,
									 3 * 150 + 2 * SimpleCabinetModel::kBoardThickness,
									 800);

	FrontModel frontModel(simpleCabinet.GetFrontModelOrigin(),
						  simpleCabinet.GetFrontWidth(),
						  simpleCabinet.GetFrontHeight());

	CHECK_EQUAL(3, frontModel.GetNumRows());
	CHECK_EQUAL(2, frontModel.GetNumColumns());
}

Now is the right time to flesh out GetNumRows() and GetNumColumns().

class FrontModel {

public:

	long GetNumRows() const {
		return MyMathUtils::fdiv(fHeight, SimpleCabinetModel::kSegmentHeight);
	}

	long GetNumColumns() const {
		return MyMathUtils::fdiv(fWidth, SimpleCabinetModel::kSegmentWidth);
	}
};

In order to get the number of front tiles fitting into a row, we need to divide the overall width available for the front tiles and divide it (as in division of integers) by the width of a segment. Same for the number of front tiles fitting into a column.

Where are we at? We now have code for calculating the number of tiles in x direction (columns) and z direction (rows). If we would have a function computing the x, y & z position of a front tile at a given row & column we could certainly beef up SimpleCabinetCreator::CreateFrom() with a nice loop placing all the front tiles. Let’s write a test for this function computing a tiles position:

TEST_N(FrontModelPositionOfARowColumn)
{
	SimpleCabinetModel simpleCabinet(1200, 720, 800);

	FrontModel frontModel(simpleCabinet.GetFrontModelOrigin(),
						  simpleCabinet.GetFrontWidth(),
						  simpleCabinet.GetFrontHeight());

	WorldPt3 expectedPosition = frontModel.GetOrigin() +
								WorldPt3(3 * SimpleCabinetModel::kSegmentWidth, 0,
										 2 * SimpleCabinetModel::kSegmentHeight)
	CHECK_EQUAL(expectedPosition,
				frontModel.GetSegmentPosition(3, 2));
}

Here’s the code to make the test pass:

class FrontModel {

public:

	WorldPt3 GetSegmentPosition(long column, long row) const
	{
		WorldPt3 position(GetOrigin());

		position += WorldPt3(column * fSegmentWidth,
							 0,
							 row * fSegmentHeight);

		return position;
	}
};

And for the grand final of this episode, let’s tackle placing the front tile symbols in SimpleCabinetCreator::CreateFrom(). With the preparatory work we’ve done in this episode it should be pretty straightforward – and it is:

	void CreateFrom(const FrontModel& frontModel) {

		for (long i = 0; i  frontModel.GetNumColumns(); i++)
			for (long j = 0; j < frontModel.GetNumRows(); j++) {
				VWObject frontSegment = gSDK->PlaceSymbolByNameN(frontModel.GetFrontSymbolName(), WorldPt(0, 0));
				frontSegment.MoveObject3D(frontModel.GetSegmentPosition(i, j));
				fSimpleCabinet.AddObject(frontSegment);
			}
	}

Tune in next week when you hear Nurse Piggy say: “Are we done yet? I have a date with a certain frog for dinner… “.

Previous Episode | Next Episode