To Unit Test or Not to Unit Test… which Visual Studio Version?

Peter Provost has started a grass roots movement (aka petition) here to include Unit Testing in all the versions of Visual Studio.
Now seeing that I am an Microsoft Employee, I feel I must put in my 2 cents to defend the position of only including this in Visual Studio Team System.  Programming is hard, I don’t think anyone disagrees.  Unit Testing is one way to increase code confidence and reduce bugs.  There are many other practices to help us (developers) make our code / products better.  This is the goal of Team System: integrate these practices (Unit Testing, Stress Testing, Static Analysis, Work flow, Source Control, Code Coverage) so we can me more productive and better developers.  So if all you want is Unit Testing is it because that is all you are doing? I doubt it.  The integration is what makes Team System the price of admission.

I also am listing a pointer to Jason Anderson’s post that I think matches what I am saying.

Comments (12)

  1. Brad Wilson says:

    As long as we get it all in MSDN Universal, then I guess we don’t care. But nobody will commit to that, because it’s a political decision (the "worth" of a group) that’s driving the differentiation between "Visual Studio" (one group) and "Visual Studio Team System" (another group).

    You know what? We don’t care about stupid internal political struggles for the survival of a group. The fact is, if it doesn’t ship with MSDN Universal, it will have nearly zero uptake. If you want to make it mean something, and have people use and benefit from it, then give it to them.

  2. Simon Hodd says:

    The point is that unlike the other practices (Stress Testing, Static Analysis, Code Coverage etc) writing unit tests is part of coding, not a step that can be done later by someone else (with other tools).

    Unit tests are preferably written before the code under test.

    So if the MS unit testing support requires Team System, I have only two choices: Give all developers Team System or use another unit testing framework.

  3. My simple view give us unit testing, code coverage and fxCop then start differentiating. These are the bits that I’d want today. Code Coverage is one area I’ve been actively looking at for a while and the version in the CTP is pretty darn good.

  4. Robin Curry says:

    A strongly typed compiler is also one way to increase code confidence and reduce bugs. Will it only be included in Team System as well? Of course not.

    The implicit message that Microsoft is sending by only including Unit Testing in Team System is that this practice is only valuable in a team setting and/or that it’s value is only significant when integrated with these other tools. This is certainly not the case.

    Unit Testing arguably provides as much development value to individual development as a strongly typed compiler (and some people in the community are arguing this). It’s intrinsic value has very little to do with integration as suggested in your blog post – the integration may serve to increase it’s value in a team environment, but the tool itself should be put in the hands of all developers.

    On a personal note, however, as long it is in the Universal subscription, I’ll be fine.

  5. Darron says:

    This issue seems to be quite the dividing rod. On one hand I have an MSDN Universal subscription, so I will have the "Team system" anyway.

    My personal feelings are this. Unit testing support should be in all versions, whereas maybe code coverage, and all the other bells and whistles should stay in an upgraded product.

  6. Brad Wilson says:


    Who told you that you have a guarantee of getting any of the Team System Visual Studio versions with MSDN Universal? And who says that you’ll be getting the Team System Sever with MSDN Universal, even if you do get Team System versions of Visual Studio? And who says that the Team System Unit Testing component will work without the server?

    In my mind, these are unanswered questions. As far as I know, there has been no _official_ commitment yet on what goes where and at what cost. I think it’s foolish to assume that, just because something is useful to developers, that they will get it for free with MSDN Universal.

  7. Ron Jeffries says:

    Integrating "the practices" is good. But agile software development is integrated by people, not by software. People become powerful teams on their own, not because they own an expensive piece of software. And //most importantly// they become teams in their own style.

    It may make sense for Team System to have all the tools in one package. It might possibly make sense to have them integrated, if it can be done without defining a particular way of doing things.

    But the tools, particularly Test-Driven Development, the reason why xUnit systems exist, is a grass-roots, one or two developer at a time thing. The tools belong on every developers desk — every developer in the world, not every developer whose company can afford VSTS.

    And the /process/? That definitely belongs to the team, not to some software package. VS and VSTS need to enable things, not to control them.