A major focus of VS2010 is in the Testing space.  One of new tools allows testers to capture trace information during testing that can then be linked to bug work items when they are found.  The trace information that can be captured consists of videos of the testing session, screen shots, historical debug files (so that you can walk the stack trace of what happened), and even a snapshot of the VM that the test was being run in so that the developer can go to the exact machine where the bug was encountered.  The goal of that effort is to reduce the amount of times a No Repro answer comes back from devs for bugs that are filed.  With the trace information collected the developer has many avenues to research the how, why, and what in relation to the filed bug.

  Other capabilities showing up in VSTS is the ability to determine what tests cover the code that is being changed in a changeset and thus become key candidates to be run during the testing process.  Gated Checkin is a new feature in VSTS/TFS 2010 – today a somewhat similar feature can be found on Code Plex called Buddy Build.  The goal of the Gated Checkin feature is to help reduce the number of broken builds.  A checkin before being committed when the Gated Checkin feature is turned on will be run in isolation with the latest version of the checked in code to validate that the code builds successfully and then depending on configuration that some or all of the tests pass. 

  Another feature related to build (but not Gated Checkin per se although I would imagine it could be applied during a Gated Checkin build) is Architecture validation.  With 2005/2008 the Architect SKU provided little value it is being overhauled dramatically with 2010 (the new features with it deserve their own post altogether).  One of the new capabilities showing up is an architecture validation step associated with the new Layer diagrams.  This will ensure that code is not calling outside of the layers it is allowed to call.  If that happens these will show up as architecture errors in the build.  They also showed the Architecture Explorer which enables you to do NDepend like dependency analysis quickly and easily from within Visual Studio.  I inquired on the licensing strategy to determine what access the Developer SKU will have to these types of things.  The answer was that the Developer SKU will be able to read the artifacts output and navigate them (zoom in and out, drill in and out), but not produce them.  That seemed to be a reasonable trade-off I thought – the Architect SKU potentially has value now, but the Developer SKU were everything seems to come together isn’t left out in the cold completely. 

  The last thing that was shown was the Automated Testing capabilities which will be available for both Web and Winforms.  They hope by RTM to have a beta of WPF support.  You get an impressive ability to reach into Webforms and Winforms and validate the content of controls (the only way to truly appreciate this is to see a demo of how slick it works).  MS will enable a greater degree of test automation with this capability I believe (at a lower overall price than the tools available today), but it is also beefing up the manual test case side of the story as well realizing that there will always be things that for one reason or another can’t be or shouldn’t be automated.