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
- Anonymous
June 13, 2004
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. - Anonymous
June 13, 2004
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. - Anonymous
June 13, 2004
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. - Anonymous
June 13, 2004
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. - Anonymous
June 14, 2004
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. - Anonymous
June 14, 2004
The comment has been removed - Anonymous
July 06, 2004
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.