Rosario April 2008 CTP Investigation (Part 6) - Developer
Continued from http://dotnet.org.za/willy/archive/2008/06/02/rosario-april-ctp-investigation-part-5-build.aspx.
What can the team improve in VSTS in the Team Edition for Software Developers ... one may wonder ... when most developers hardly scratch the surface of the development, debugging and testing powerhouse?!? Well, in this brief excursion we will look at the historical debugger, test impact analysis and the standalone debugger. There is lots more ... but again we are going to scratch the surface q:)
Historical Debugger
We start the sample "Patient Monitoring" application in debugger mode, viewing patient details for Jesper Ahberg and then Andrew Cencini.
We see that the picture for Andrew is missing, realising that in today's debugging world we have just stepped past the problem and would need to reset breakpoints and restart the debugging session ... in this case a quick exercise, but normally a nightmare that can take hours of initialisation and careful debugging.
So what can we so in Rosario? Can we actually go back to the future?
We select the "Debug History" window and then click on "Click here to break into the debugger".
We see debugging history, i.e. we can go back in time and look at the evidence. Expanding the node "onPatientRoster3DOverLaySelectionChanged()", where we can see that an exception was encountered, with some details.
Looking at the history, which indicates that an image cannot be found and the actual images repository, we can quickly deduce that the path we are looking for is \Image\..., instead of \Images\...
History debugging is therefore a nifty feature. We can control the amount of history debugging information collection, by selecting the level between off, low and high as shown:
Code Metrics
Nothing has changed in this area, but I think it is worth mentioning that there are a number of cool features with the Code Metrics, namely the ability to filter on ranges within a specific metric, ability to load the data into Excel for further formatting and the ability to create a work item. Take note of these in Visual Studio 2008 (Orcas) and use them!
Code Analysis
Running Code Analysis results in the same scary list of things to consider as in the current release in Visual Studio 2008.
What is new, is the ability to select the criteria.
Switching from "all rules" to "Release Criteria Checklist", focuses on the criteria important for the release of the product and we can immediately see a drop from 19 to 6 warning:
To create criteria, we select Customize and define our custom world. This is really easy to use and "cool".
Test Impact Analysis
Let us assume that we have the courage to deal with the warning list generated by the static code analysis. We click on one of them, the CA1823 warning.
Looking at the Test View window, we notice nothing strange. The Group by "Test Impact Status" looks interesting, however, when we group by this criteria we see a long list of "Not Impacted".
However, when we start making changes to the code by inserting a silly comment:
and then selecting save, we notice a new group appearing, namely "Recommended". WOW ... by making a simple change, the tool guides us as to which tests are impacted and are recommended to be re-run.
So, let's run the tests as recommended ...
... and the "recommended" changes to "verified" when the tests pass.
Standalone Debugger
Ever wondered how 'nice' it would be to be able to drag an instance of the VS debugger to a system, without installing Visual Studio?
Aaaahhhhh, let's select the Debug Menu and notice the "Create Standalone Debugger" menu item.
We have the option of selecting|creating a directory, then Visual Studio performs a copy.
Looking at the directory we have a set of binary files sitting in the directory ... a standalone copy of the debugger!
Next we start the demo application by hand ... no trace of Visual Studio! Then we execute the VSDebug.exe program in the directory we dumped the standalone debugger.
We can attach to the process ...
Load the relevant source file, create a breakpoint ... and then proceed a debugging session "as if" we were debugging in Visual Studio. In fact we are debugging in a standalone instance of the VS debugger.
Another great feature is the ability to dump for a process or a 'crashing process'. The steps are simple:
- Open up the Attach To Process dialog, under Tools | Attach To Process menu.
- Select Native debugging, which you find under Select ... button.
- Pick the process to debug.
- Break into that process.
- Save the dump.|
- How to debug such a dump is beyond this post ... refer to http://msdn.microsoft.com/en-us/library/d5zhxt22(VS.80).aspx for details.
The Standalone Debugger is a non-persistent instance of the Visual Studio debugger that you can potentially run from a USB drive, in other words you can now carry the debugger with you!
Some features are not supported in the standalone debugger, such as:
- 64-debugging on Itanium computers
- MPI debugging
- Just-in-time debugging
- Edit and Continue
- Design-time debugging
- Remote debugging
- Debugging dumps
- Custom visualizers
- Autoexp.dat
- The Exception Assistant
- Automation of the debugger
- SQL debugging
- Script debugging
- Silverlight
... but that is not really a limitation, the fact we now have a mobile debugger is exciting
Conclusion
The enhancements seem subtle, but features such as the historical debugger can be immensely useful and a huge time saver.
The control over static code analysis will likely mean that project teams will start using the feature, instead of fearing it as a confusing and often over-kill check-in blocker.
The most exciting enhancement we have looked at is, in my humble opinion, the test impact analysis. Why? These features a not a magic potion, but they do assist us with the quest for zero defects by highlighting what should be tested. It makes regression and continuous testing a lot more feasible!
Our objective should be to:
- Learn from our mistakes.
- Strive for defect free solutions … it is possible.
- Avoid cost, frustrated and stressed out solution teams, continuously fixing defects.
- Avoid dissatisfied customers.
- Reduce solution cost, by avoiding expensive defect investigation and resolution exercises.
We should aim for the best strategy, i.e. defect prevention, but to start we should look at a strategy to help us detect and analyse defects|bugs|etc. and learn to drive and ensure solution quality. Structured and documented solution reviews, post-mortem's and defect statistics analysis should be part of our strategy going forward, so that we can document and refer-back to learning's.
The tools we have looked at in this mini-series equip the developer with the tools and guidance to achieve the strategy to a large extent. The features are therefore ultra cool and get my sap of approval!
The standalone debugger gives us mobility!
My personal rating for the Team Edition for Software Developer improvements in Rosario at this stage is: 
/ 5 smiles.
Next
... part 7 will look at Team Edition for Software Tester and finally in part 8 Team Edition for Database Professional.