Our dev stack at my company is a home brew of…
- Visual Studio 2008 Professional - core IDE
- ReSharper - our third party refactoring tool of choice
- TortoiseSVN – our Subversion control client of choice
- MbUnit – Our unit testing framework of choice
- TestDriven.NET - Visual Studio add-in for filling in the integration gaps between the IDE and MbUnit (or any other testing framework)
- .NET Memory Profiler and dotTrace – only a few folks have these currently, but I’d like to make profiling for performance and memory management a first class aspect of our dev cycle – so everyone’s going to need a profiler of some kind for that to work.
- VisualSVN - Some folks have sprung out of their own pocket to buy licenses for to have an fully integrated SVN client experience directly in Visual Studio (I’m one of those people).
I was one of the folks driving the adoption of most of these “additional” (“additional” has come to mean anything that’s not Visual Studio) things like ReSharper and TD.NET as they were tools that I came to see as invaluable in my prior jobs. Most around me have came to realize the value of these tools. As we scale out our development processes to a wider and wider scope of developers in our organization (beyond our Chicago walls), more and more people are coming into the fold that just aren’t as interested in this stuff as others. They don’t want to (or can’t) see the value that tools like TestDriven.NET provide and see these as additional friction and noise. Alpha geeks of course don’t see it that way, but Mort isn’t an Alpha geek. I’m happy with our stack personally, but I would agree that there’s some noise there.
I remember when Microsoft release Team System they were pushing hard the seamless integration value-add story. I remember reading a lot of blog posts from folks arguing that the current open source and third party tool stack was low-friction and the value-add of seamless integration that Team System provided was a farce. I’ve seen both sides of that argument over the years, but now that I’m in a shop working with over 50 developers, I see our current dev stack as more and more of a problem. Versioning issues between these tools can’t be a real pain in the neck to deal with. And each time we upgrade to the latest version of Visual Studio, it seems like the procurement process of these other commercial tools has to be restarted. My company, like a lot of companies out there, bought MSDN subscriptions for everyone and they see that as the development tools budget each year. Anything additional that must be legal-reviewed/purchased/mass-deployed/adopted, is friction and noise.
With all this in mind, I’ve been thinking more and more about Team System. I like the idea of having the unit test framework and runner application(s) packaged with the IDE. While I’ve never used the profiling tools and static analysis tools in Team System, having those packaged into the IDE as well is very appealing. Even if these tools included in Team System weren’t necessarily best of bread – if they were compelling (and low friction) then I’m interested. I don’t think Team System is approachable for us right now, but I’ve been thinking a lot about the friction:value ratio of a Team System dev stack. After reading a few posts like Mike Hadlow’s MSTest is sapping my will to live post, I remember what I didn’t like about MSTest when I first looked at it, and my interest levels dropped.
In quest for a most tactical simplification of our dev stack, I was curious to see if I could remove TestDriven.NET from the mix. To be clear, I love TestDriven.NET, and I’ll probably continue to use it no matter what we prescribe to our organization. However, I don’t like having TestDriven.NET as our primary test runner in Visual Studio – I think it should be an optional component in our stack. There’s already a native test runner inside Visual Studio 2008 – it’s for MSTest of course, but it’s there none the less. ReSharper also has it’s own test runner living within Visual Studio. That’s never been useful to us because it doesn’t support MbUnit (only NUnit). Today I decided to invest a little time in trying to get ReSharper’s test runner to run my MbUnit tests. I knew this problem had already been solved with an open source project, but because this capability doesn’t come out of the box with ReSharper, it made me nervous (I want less plugins – not more). I pulled down the source to the mbunit-resharper project on Google Code, updated the references to the latest 4.1 version of ReSharper and the latest 2.4.2 version of MbUnit. To my surprise it just worked.
My initial fears we ungrounded. This doesn’t require a new VS plugin. It’s just an additional assembly that ReSharper will load should you choose to put it in it’s AppData folder. Doing so makes MbUnit available in the unit test providers setting in ReSharper –> Options –> Unit Testing.
I don’t know how much this solves, but removing TestDriven.NET out of the mix (as much as I love it) does feel like it removes significant friction. MbUnit is low friction by itself, but it can have versioning issues with TestDriven.NET resulting in friction. Without TestDriven.NET, MbUnit’s friction count becomes 0. I think I’m going to use ReSharper’s test runner as my primary runner for a few days and see how I feel. I’m pretty happy with this at first glance. Sadly, this should be supported right out of the box IMO.