Treading on thin ice

casper — Sat, 02 Jun 2007 11:22:00 GMT

I wasn't sure if I should comment on this, but the power of Agile and good programming compel me. I love TestDrive.Net. I've shown it to my group on more than one occasion and will tell anyone who will listen about it. Yes, the next version of Visual Studio is greatly improving the test-first experience, but in the meantime this is without a doubt one of the best tools you can buy for coding.

I can't argue that Jamie is in the right - he's definitely not. The EULA for VS Express clearly states that you cannot write extensions for the free version of the application. At the same time, I believe test-first development is crucial to learning to be a good programmer, and depriving hobbyists of this wonderful extension is cruel at best. I don't know what the solution is, and I'm definitely not a lawyer, but I really hope everyone can come to an amicable end to this situation.

Unit testing moving to VS Pro!

casper — Wed, 28 Mar 2007 10:44:00 GMT

Due to popular demand, the unit testing features normally found only in Visual Studio Team System are going to be available in the Pro SKU of Orcas. You can find more details on the announcement here. It's great to see the VS team continue to take an interest in the TDD-oriented crowd.

The occasional difficulty with being a proper developer

casper — Tue, 06 Feb 2007 14:04:00 GMT

As children, we're often taught the "proper" way to do a task. Usually the advice is promptly ignored and replaced by a quicker or easier method. At some later point in life, we realise why it's better to use the originally prescribed route and then make the extra effort to do it "properly".

Coding is no different: a classic example in C++ would be the use of const. I think most programmers are taught, whether in school or the real world, the value of const and how to use it effectively. Inevitably they'll forget to use it at the start of a project ("oh it's too small to worry about that") and then realise half-way through that it's required. This is quickly followed by the wailing and gnashing of teeth as the code is retro-fitted and several cans of [insert your favourite liquid here] are consumed. I can say from experience that introducing const into even a small application can take a day or two.

What does all this have to do with my current project? Well let me take a few seemingly separate practices that I consider "proper":

Designing code through examples (a.k.a. TDD)
Documenting method signatures with XML tags (e.g. /// <summary>)
Enabling 'treat warnings as errors'

I'm at the stage where phase one of the control is complete and it's wrapped up nicely in its own assembly with the unit tests. Great. I flip on the "Output XML documentation file" in the project properties to see if I've missed any public methods or properties. After the next build VS 2005 promptly gives me 2²⁴-1 warnings/errors (ballpark figure).

I've really only missed three properties, but now it's complaining about all my unit tests and fixtures. TDD.Net won't work unless the classes and methods are marked as public so there's no hope of making them all internal. I have no intention of writing comments for my unit tests; that's why I use extremely descriptive method names.

Where does this leave me? I have two choices:

Wrap all the fixtures in #pragma warning disable 1591
Move all unit tests to a separate assembly

I grudgingly chose #2. My first options was [3. Exclude unit tests from non-debug builds, and only enable XML generation in those builds]. As I found out, you can't do that in VS 2005; it must have been a little-used features of VC6</sarcasm>. Option one makes the source file looks messy, and I have a touch of OCD when it comes to neatness. I blame Scott for introducing me to the 'View White Space' option in VS.

Moving the fixtures to a new assembly wasn't that tough; what I ran into was the problem that now my unit tests can't access the internal classes in the original assembly. So another fork in the road appears before me:

Move all unit tests to a separate assembly. Make all classes in original assembly public.
Move all unit tests to a separate assembly. Add an [InternalsVisibleTo()] attribute to the original assembly.

Choosing 2a results in immediate death, just like the classic Choose Your Own Adventure books, so I move along 2b and eventually reach the proper ending.

I'm going to go out on a limb and say that the developers on the VS team who coded these features didn't do test-first development. If they had, I'm pretty sure doing things like this would be less painful. But there is hope—I know for a fact that they're putting a lot of effort into making TDD work as expected into Orcas and future versions. In the meantime, being a ‘proper’ developer will still require a little extra effort. But, as always, it's worth it.

Adventures of an aspiring agile developer in a not-quite agile world : VS

Treading on thin ice

Unit testing moving to VS Pro!

The occasional difficulty with being a proper developer