Partager via

The occasional difficulty with being a proper developer

  • Article

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":

  1. Designing code through examples (a.k.a. TDD)
  2. Documenting method signatures with XML tags (e.g. /// <summary>)
  3. 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 224-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:

  1. Wrap all the fixtures in #pragma warning disable 1591
  2. 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:

  1. Move all  unit tests to a separate assembly. Make all classes in original assembly public.
  2. 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.