I know there is nothing that I can say that will be viewed objectively, because I am a Microsoft employee and I have been tangentially involved with the VS Team System development team (I am the development lead for the patterns & practices). That said, I would like to dip my toe in the fire of “Why unit testing in Visual Studio Team System” which I translate into “Why unit testing in Visual Studio Team System and not just plain Visual Studio”. For background information see the following posts:
There are a number of questions that come to mind for me with this issue. Why is unit testing singled out? What about the other tools, like source code control, and static analysis, profiling, etc? Certainly these tools are valuable during development. So, that said why focus just on unit testing? Since nobody answered, I will jump in. J
I think focusing on an individual tool clouds the issue. Certainly if we are talking about one and only one tool then I don’t think there would be any argument, it should be included. If we are talking about more than one tool, which in the case of Visual Studio Team System then it gets more complicated. In many cases I can solve an individual tool problem with an existing tool. For example, I can solve the unit testing problem today with NUnit and NUnit Add-in. If I want to do static analysis I can use FxCop. If I want to do source code control I can use any number of tools (Clearcase, StarTeam, Perforce, etc.). The problem that I have is putting the whole thing together and getting some sort of consistent experience. In my consulting work I would often have clients who strung together their development environment with a myriad of scripts and various versions of tools, some built in-house, some purchased, etc. The first thing that came to mind was how many people would use these company’s products if they saw the mess that was used to produce them. The closest analogy that I can think of is; you would not eat at a restaurant if you saw the food being prepared. That said it is critically important that these tools (unit testing, static analysis, profiling, source code control) be used during development because they have shown productivity and quality improvements when used individually. Visual Studio Team System provides an environment which enables a number of development tools to be used and the user can get a consistent experience from implementation to implementation. I don’t have to write a custom task for my unit testing tool in MSBuild, I can use the one provided. I don’t have to figure out some goofy directory hierarchy so I can share my FxCop rules amongst a team of developers. I can easily run my unit tests locally on my development machine and then if someone in the QA department needs to run them they can do it to without having to have a custom development setup. I could go on and I probably should but it is for problems like these that Visual Studio Team System was developed and I believe gets to the root of why these tools are not adopted in a broad sense.
Of course this is my opinion and in Dennis Miller’s words “I could be wrong”. If you think I am off base please feel free to let me know.