Dr. Neil calls Microsoft out for their attempt to redefine Test-Driven Development to suite the product they have developed (Team System). I personally thing VSTS will help a great number of teams define a process for their group. Many development team I talk to don't have an actual process. It's more of the wild west. I use a mixture of XP an Scrum, and our Agile practices are very structured and disciplined. Waterfall falls somewhere in the middle on a discipline scale (and far out there on a reality scale). For cowboy teams or teams whose process isn't reliably producing working software, I think VSTS will help to inforce a more disciplined and accountable software shop. Along with any product, it will be both abused and used for good. Kudos to Microsoft for putting this product together.
With all the good that it will bring with it's increased focus on automated builds, static code analysis and automated testing, it has missed the boat on a few items regarding it's automated testing support or what it claims to be. VSTS does come with testing support, and it can generate test stubs from production code, but it does not inherently support test-drivent development. TDD is simple:
- RED (make a test, and make it fail)
- GREEN (write production code to make the test pass)
- REFACTOR (eliminate duplication)
It's a cycle of 1 test to 1 production scenario, and TDD is test-first unit testing that helps shape the design of the production code as it emerges. Development is "test-driven". That means that if you are developing and then generating tests, you are doing testing, but your development wasn't "test-driven", it was "test-trailored", or whatever term you want to use.
VSTS testing tools will generate test stubs from production code, but they won't generate a production method stub from a test (which is a well-used feature of Resharper). If you look at the process guidence on TDD from Microsoft, you'll notice the attempt to redefine the process to fit the tool. They should modify to the tool to fit the already-proven process.
Another falacy exists in the guidance on creating "ASP.NET unit tests". Microsoft seems to only focus on unit testing as a term, but they describe integration tests. Refer to Jeremy Miller's post about the different types of tests. Unit tests test code in isolation. In other words, they test code while isolating dependencies from the code. Unit tests should always pass. Unit test only run custom code. If 3rd-party libaries or frameworks are required for a test to pass, then it is, by definition, not a unit test. It then becomes an integration test. The term "ASP.NET unit test" is a falacy. These tests, as Microsoft describes them, include the development webserver in the testing stack. This is a pretty significant dependency, and these are integration tests. Integration tests are important too, but they should be defined correctly.