Plugin pattern

May 8, 2007 at 12:20 PM
With all the various options and ideas flying around for Tree Surgeon I wanted to mention the approach I'm thinking for supporting all of these ideas. The plugin pattern is great for this so I see us creating things like a UnitTestPlugin, ToolPlugin, BuildFilePlugin, VisualStudioVersionPlugin, etc. This will support all the various flavours out there and let us extend the system rather than building lots of code in the core to support anything new that comes along.
May 10, 2007 at 8:47 PM
So you see those ones as being the base classes (or interfaces) for more specialized versions? E.g. NUnitPlugin and MbUnitPlugin deriving from UnitTestPlugin. And the user can download which ever ones suit his needs?

I'm loving the idea but am wondering about interdependencies 'twixt the plugins. For example, the NAntPlugin will behave differently depending on the selected Visual Studio Version. And some combinations are not allowed (like MSBuild and VS2003). How can we handle that with a plugin pattern? Or do we make the unit test framework, build file, visual studio version, etc, explicit behaviours of the application and implement plugins for each one?
May 12, 2007 at 3:02 PM
Yes, something like that. Maybe a PluginBase class then some more specialized sub-classes (maybe a ConsolePlugin vs a DialogPlugin vs a VisualStudioPlugin) finally with a UnitTestPlugin below that finishing up with a NUnit and MBUnit one. It's a lot of classes, but I think it might be the most flexible. I'm thinking along the lines of what QERadient did with plugins. They separated them out from user interface ones vs automated ones. This way we can handle visual studio vs non-visual studio and maybe have versions of each in the tree (I should probably throw together the classes into a class diagram in VS2005 to show this). The plugin should be self-contained but be given whatever info it needs (for example what version of Visual Studio it's running against) which will let it handle how to deal with the output it produces. Yes, it's all swirling around in my head right now but probably a simple spike should prove out my ideas.
May 24, 2007 at 9:19 PM
I've been taking TreeSurgeon and how it implements creation of the unit tests and linkages, and abstracted it away into a plugin pattern. Works pretty good so I'm going to go ahead and move the unit tests away into the plugin and then do the Visual Studio details this way (using unit tests as a POC and adding MBUnit). Will update the source sometime this weekend so watch for a changeset.