Developing a Vectorworks 2011 Plug-in, TDD-style – Episode 0

During a recent internal TDD code camp at extragroup, we were working on some basic TDD style katas like StringCalculator.

Some question regarding TDD & Vectorworks came up during the day:

  • “How do I develop a Vectorworks plug-in TDD style?”
  • “Is it possible to develop a Vectorworks plug-in TDD style?”

We haven’t been able to answer this question in sufficient detail during the one-day code camp, so I set out to work through a simple project. My goal is to develop a Vectorworks plug-in object – a simple cabinet. It should be defined by its dimensions:

  • Overall Width
  • Overall Height
  • Overall Depth

The front should be made of “tiles” defined by a Vectorworks symbol (think of a rectangular grid of symbols, e.g. a simple panel or a frame). This will be the fourth plug-in object parameter. If the grid of tiles won’t fit the available space precisely, some additional blind front panels to the right and to the top of the grid should be added. To keep things simple, the cabinet should have continuous sides, all boards are supposed to be 19mm thick (or 3/4″ for you imperial guys out there) – after all, our goal is to learn how to develop a Vectorworks plug-in object TDD-style, not to create a shipping product.

Simplecabinet

In the upcoming episodes, I won’t go into details on the actual structure of a Vectorworks plug-in, for more details on how to build a Vectorworks plug-in, please refer to http://developer.vectorworks.net. There’s also a very promising tutorial by Ryan McCuaig: Getting Started with the Vectorworks SDK. The sole focus of this series is to explore how to develop a Vectorworks plug-in object TDD-style.

I’ll be using CppUnitLite2 as my C++ unit testing framework. In order satisfy the linker in the testing only target, a GSSDKStubs.cpp file contains stubs for all old-style GS_ API functions contained in the Vectorworks SDK. This enables us to create a separate testing target (command line tool) in our Xcode project linking the VW Foundation Classes while still mixing Vectorworks API calls and testing code in the same source freely. Having a separate testing target is a huge time-saver because it allows me to execute & test the pieces of our code which aren’t dependent on Vectorworks without actually starting up the Vectorworks application (which may take a moment or two).

Additionally, the testing code is also executed in the plug-in’s modules main function when loaded into Vectorworks:

if (action == kVCOMRegisterInterfaces) {
	TestResultStdErr result;
	TestRegistry::Instance().Run(result);
	if (result.FailureCount())
		Debugger();
}

That way I ensure that the testing code is run no matter which environment I’m in. If the tests work in the testing target, but fail when run in Vectorworks, I’m thrown into the debugger right away and get slapped with a rolled-up newspaper.

If you would like to go straight to the final code download, make sure to go straight to the Epilogue.

Enough of the preface. In the next episode, we’ll start coding.

Episodes so far:

You may follow this series via RSS or follow me on Twitter / Facebook.