I am excited to share that I am now an Accredited Trainer with the Lean Kanban University (http://www.leankanbanuniversity.com). This means that I can teach Kanban practitioner courses. The LKU is a great group led by David Anderson that is looking to help people learn and adopt the Kanban Method.
If you are interested in training I have a course schedule here (http://robmaherconsulting.eventbrite.com/) or please get in touch if you would like to organise training in a different location.
Like Unit Testing, Code Coverage has undergone significant change in VS 2012. Mostly the changes have simplified the process from VS 2010. Want to see code coverage now? How about right click the test and select Analyze Code Coverage. Sure beats what you had to do in VS 2010.
NB This information is compiled from two Microsoft blogs plus my own tinkering. The blogs have more detail than explained here. Check them out at
Let’s get this one out of the way quick. Code Coverage is available in Ultimate and Premium editions. Moving on…
So how does the new coverage tool know what to include or exclude? There used to be the TestSettings file that was used to specify what to include / exclude.
The new tool includes binaries “as long as these binaries are a part of your solution, and get called by any of your test cases under execution”
Ok makes sense. But what about binaries that are not part of my solution? What if I have a file reference to a different binary. Well that won’t show up. If you want to see that included in your code coverage stats then you need to do some work.
VS2012 has a new file for this called a .runsettingsfile. This is an xml file that contains which binaries to include or exclude. In RC you will need to add a new xml file to your solution and name it something.runSettings. (extension is important here) The TestSettings file is not used anymore as that was bound to MSTest and would not support the new test runner plug in architecture.
You can then copy some boilerplate text into the xml file (I am sure that the tooling will be sorted by RTM), adjust what you want to include / exclude. Finally tell you solution to use the runsetttings file and hey presto, all should be good.
So lets have a go. Suppose I have the following structure.
UnitTestProject A that has a project reference to SUT.dll. These two are in the same solution so all good so far. However SUT.dll has a file reference to Account.dll. Runing code coverage from UnitTestProject A gives me.
As you can see we only get the code coverage for UnitTestProject A and the SUT.dll. This is because they are in the same solution.
So we now right click our solution, add new item, xml file. Call it CodeCoverage.runsettings (first part of the name doesn’t matter)
Now add the following xml and save.
<?xml version="1.0" encoding="utf-8"?>
<RunSettings>
<DataCollectionRunSettings>
<DataCollectors>
<DataCollector friendlyName="Code Coverage"uri="datacollector://Microsoft/CodeCoverage/2.0"assemblyQualifiedName="Microsoft.VisualStudio.Coverage.DynamicCoverageDataCollector, Microsoft.VisualStudio.TraceCollector, Version=11.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a">
<Configuration>
<CodeCoverage>
<ModulePaths>
<!--
About include/exclude lists:
Empty "Include" clauses imply all; empty "Exclude" clauses imply none.
Each element in the list is a regular expression (ECMAScript syntax).
An item must first match at least one entry in the include list to be included.
Included items must then not match any entries in the exclude list to remain included.
It is considered an error to exclude all items from instrumentation as no data would be collected.
-->
<Include>
<ModulePath>.*\\UnitTestProject1\.dll</ModulePath>
</Include>
<Exclude>
<ModulePath>.*CPPUnitTestFramework.*</ModulePath>
</Exclude>
</ModulePaths>
<UseVerifiableInstrumentation>True</UseVerifiableInstrumentation>
<AllowLowIntegrityProcesses>True</AllowLowIntegrityProcesses>
<CollectFromChildProcesses>True</CollectFromChildProcesses>
<CollectAspDotNet>False</CollectAspDotNet>
<!--
Additional paths to search for symbol files. Symbols must be found for modules to be instrumented.
If symbols are alongside the binaries, they are automatically picked up. Otherwise specify the here.
Note that searching for symbols increases code coverage runtime. So keep this small and local.
<SymbolSearchPaths>
<Path>C:\Users\User\Documents\Visual Studio 11\Projects\ProjectX\bin\Debug</Path>
<Path>\\mybuildshare\builds\ProjectX</Path>
</SymbolSearchPaths>
-->
<Functions>
<Exclude>
<Function>^std::.*</Function>
<Function>^ATL::.*</Function>
<Function>.*::__GetTestMethodInfo.*</Function>
<Function>^Microsoft::VisualStudio::CppCodeCoverageFramework::.*</Function>
<Function>^Microsoft::VisualStudio::CppUnitTestFramework::.*</Function>
<Function>.*::YOU_CAN_ONLY_DESIGNATE_ONE_.*</Function>
</Exclude>
</Functions>
<Attributes>
<Exclude>
<Attribute>^System.Diagnostics.DebuggerHiddenAttribute$</Attribute>
<Attribute>^System.Diagnostics.DebuggerNonUserCodeAttribute$</Attribute>
<Attribute>^System.Runtime.CompilerServices.CompilerGeneratedAttribute$</Attribute>
<Attribute>^System.CodeDom.Compiler.GeneratedCodeAttribute$</Attribute>
<Attribute>^System.Diagnostics.CodeAnalysis.ExcludeFromCodeCoverageAttribute$</Attribute>
</Exclude>
</Attributes>
<Sources>
<Exclude>
<Source>.*\\atlmfc\\.*</Source>
<Source>.*\\vctools\\.*</Source>
<Source>.*\\public\\sdk\\.*</Source>
<Source>.*\\microsoft sdks\\.*</Source>
<Source>.*\\vc\\include\\.*</Source>
</Exclude>
</Sources>
<CompanyNames>
<Exclude>
<CompanyName>.*microsoft.*</CompanyName>
</Exclude>
</CompanyNames>
<PublicKeyTokens>
<Exclude>
<PublicKeyToken>^B77A5C561934E089$</PublicKeyToken>
<PublicKeyToken>^B03F5F7F11D50A3A$</PublicKeyToken>
<PublicKeyToken>^31BF3856AD364E35$</PublicKeyToken>
<PublicKeyToken>^89845DCD8080CC91$</PublicKeyToken>
<PublicKeyToken>^71E9BCE111E9429C$</PublicKeyToken>
<PublicKeyToken>^8F50407C4E9E73B6$</PublicKeyToken>
<PublicKeyToken>^E361AF139669C375$</PublicKeyToken>
</Exclude>
</PublicKeyTokens>
</CodeCoverage>
</Configuration>
</DataCollector>
</DataCollectors>
</DataCollectionRunSettings>
</RunSettings>
This is now a default runSettings file. Next we need to make sure that our extra binary gets included. To do this we can make sure that our Include section is empty (include everything.) Change the include section to look like
Finally go to the Test menu, select TestSettings, select TestSettings file. Select your runsettings file and re-run the code coverage. We now see
All of our binaries are included!
So lets get back to IntelliTrace. We are going to start out and see what it can do for us.
I talked a bit in Part 1 about what IntelliTrace was, so go check that out if you are unsure.
At an extremely high level, IntelliTrace works by collecting debugger state information during execution and saving it to a file. We will get into more of the detail later but that is enough to get us started. The data in this file can then be used to ‘replay’ the debugging session, step forwards and backwards and examine various information.
It’s important to understand from the beginning that IntelliTrace will not capture everything. The product group have had to balance performance considerations with the amount of data collected. So if you are expecting a full fidelity debugging experience with no performance loss you are going to be disappointed.
That said, the data that is collected is configurable and is tremendously useful. There are 3 main options around data collection.
IntelliTrace Events – This is on by default. Microsoft have defined 150ish events. This is instrumentation that they have added to the product. By default not every event is turned on for capture but the most common are enabled. To see this list you can go to Tools –> Options –> IntelliTrace and select Diagnostic Events.
So what gets captured at these events. Well, we will dig into more details later, but the short answer is “a small amount of data that is custom tuned to be relevant to the specific event being examined.” If you try and navigate backwards to see what happened exactly before that event you probably will see the IntelliTrace data not captured message. This is IntelliTrace saying – “sorry didn’t capture that.”
Later in this series we will see how this event data collection is configured. An example of this is opening a file. The file name is collected.
Calls Mode
When Calls Mode is turned on expect a performance hit. We are now instrumenting much more data and so this will come at a cost.
Calls mode instruments the entry and exit calls of every method in your code, including their parameters. Note that this is in addition to any collection based on IntelliTrace events. So you can expect to be able to see exactly which of your functions were hit, as well as what data was passed into them and what data they returned.
This collection works for one level of indirection for objects passed to/from the function. So you won’t get all the data for deep nested objects.
Debugger Break Points
If you had any break points set when you ran the application then these are also recognised by IntelliTrace and have special collection behaviour. At breakpoints IntelliTrace will collect local variable values and basic data types one level from objects (as with calls mode.) So at these lines you can open the locals window and see values! Breakpoints create a special type of IntelliTrace event called a debugger event (more on this later)
So now we know what our options are, how do we select an appropriate collection level. Go to Tools –> Options –> IntelliTrace
You will see that by default, IntelliTrace is enabled and the collection level is IntelliTrace events only. In this dialog we can select Events and Call Information (Calls mode)
Obviously we can place a breakpoint anywhere in our code. Each breakpoint will enable local variable collection.
This has changed in SP1. Previously, the default was to write to a folder on your drive. Now this is turned off by default. So once you have SP1, IntelliTrace will not capture files on your drive by default. To check your setting choose Advanced from the Tools – > Options –> IntelliTrace menu. Here is the default on my machine
You can see from here that the file collection is turned off. If we do enable writing files then from this dialog we can also limit the amount of space that these files should take up.
So do I need to turn this on in order to use IntelliTrace – no! The new default behaviour will capture the IntelliTrace information temporarily whilst you are in a VS session. At any point in that session you can decide that you want to persist the IntelliTrace file in order to return to it later, but the default is to delete the information. We will cover this later in the series.
So that about wraps up our default collection options. We now have an overview of what IntelliTrace is and how we can choose different collection options. Next time we will start collecting some data!
The software craftsmanship movement is gaining momentum. The idea that writing software is a craft is one that you may or may not agree with, but it is hard to disagree with some of the practices that the community promotes. There are conferences and a manifest0 here that outlines the intent.
So what practices are actually involved in the craftsmanship movement? Opinions are somewhat divided but most people will point to this book as a good starting point.
It is easy to see this as a collection of the best and brightest in the industry promoting the next big thing, that can seem unattainable if you are working for a big corporate. Deadlines, ‘heavy management’, ‘good enough thinking’ might be familiar friends. Sure, the people of the cusp of this are notable ‘big thinkers’ but this movement has become more than this, and there are ways to bring this into to your organisation.
I am not going to give you a definition of the practices that I think make up a ‘craftsman’ but writing SOLID code is a great start. But it’s more than that. In my view a couple of key points are:-
This isn’t about building a skills matrix or sending people on courses. This is about finding time to learn new things that could be brought into the workplace to make everyone better. Building this culture takes time and effort. Some / a few people need to lead it – note when I say lead I am not necessarily talking about managers. I mean organise, facilitate, prepare. This can be done by one / a small number of passionate people.
In my view, a learning culture means a supportive failure free environment. I don’t want to get all tree-huggish here, but these are important concepts. To me supportive means that people help each other learn. This is not about one ‘expert’ that does all the teaching. This will limit learning to the experience and expertise (not to mention bias) of that ‘expert.’ Supportive should mean that no-one is left behind. If they don’t get ‘it’ then they are helped to understand.
Failure free is really about the idea that no question is too dumb, and no-one is wrong. Think that something is a class not an interface great, lets have a discussion about it. Don’t think that there is any value in TDD – let’s talk. The most valuable insights can be gained from watching how other people do it or from disagreements.
If I am going to present a talk then I will practice speaking. If I ever had to play an instrument in public (god forbid) then I would practice. One of the tenets of craftsmanship is this idea that people should practice their craft. So for us that means practicing code and everything related to coding outside of working on a product / project.
Ok, this all sounds good, but how do we do it, and how much will it cost? There are three things that I would start with., and none of them should cost any money. Feel free to try one, two or all three depending on your organisation.
Form a community. No really – do it. Find a group of like minded people within your organisation. Send out a mail to all developers about craftsmanship and see who responds. Once you get off the ground others will join – I guarantee it.
Once you have some people who are keen to participate decide on what you want to achieve. Want to be better devs? Want to learn TDD, BDD, ATDD? Want to understand and write SOLID code? Once you have a community you can move on to..
Huh? A what? A coding dojo is simply one way to achieve or practice a technique often using pair programming. There are lots of links out there but I would recommend this one for TDD. A good way to start is this.
Coding challenge announced
Changes to pair every 10 mins
Everybody pairs
Stop when someone doesn’t get it
Design comments on green bar only
Do not add code if people are unhappy with design
Use TDD
Code in iterations
I usually recommend doing a dojo at lunchtime. Bring your lunch and code whilst eating. This way it costs nothing. I would definitely promote pairing as a great way to encourage shared learning. There is nothing like watching other people code to learn new things. If you have never paired before, who cares! Give it a try.
An internal education event. OK this one takes some money. It costs time which means it costs money. If the two things above have become successful then this can be a great next step. I would start small, maybe a couple of hours one afternoon. See if your management will give you that time (hey even if you make it up later) Get a few keen people to give 30 min quick talks on things that they are passionate about. It could be things that they have learning in dojos, or technologies that they code in at home. What’s important is that they are passionate and keen to present. I am sure that people who are not part of the community / dojos will want to attend.
If that is successful then do another one, until maybe you get a full day’s conference. If management won’t give you the time then run it on a Saturday. Trust me if people don’t want to / won’t give up their Saturday then the craftsmanship movement is not for them.
Email your colleagues, start a community. Try a dojo. Take responsibility for your own development. Trust me if you don’t no-one else will.
Looking to start a craftsmanship community in your organisation? Need some help? Get in touch at info@robmaherconsulting.co.nz
IntelliTrace is one of the killer features in VS 2010 and yet seems to be one of the most under used.
Whenever I speak at user groups or events I often ask the audience who uses IntelliTrace.. Every time almost no hands go up. I am not sure if this is because it can be a bit difficult to learn or whether it hasn’t been marketed enough.
So this series is my attempt to provide a good overview of the feature set, where it works and where it doesn’t.
Over the next few posts I will drill into IntelliTrace, show how it works and how to get the best out of it
If you have any questions that you would like answered as part of this series please post a comment and I will make sure that I address them.
I am intending to collate this info into a presentation and present at Tech-Ed and some user groups.
Ok, so let’s ease our way into it. Firstly in order to view the IntelliTrace logs you will need Visual Studio 2010 Ultimate. So if you don’t have that, then you might want to download the trial edition if you want to follow along. You can download the trial here http://www.microsoft.com/visualstudio/en-us/try
MSDN docs say that IntelliTrace provides an enhanced picture of your application compared with traditional debuggers. I would probably push the boat out a bit further than that and say that it is a fantastic feature that not only makes development easier, but help diagnose those ‘impossible bugs’. If you have VS Ultimate edition and don’t make use of IntelliTrace then you are really missing out.
In my view IntelliTrace is like 2 things. The most common example is a Flight Recorder (think the indestructible black box on an aircraft) The black box enables engineers to extract the data and ‘replay’ the flight as it happened using telemetry and instrument diagnostic data. Well IntelliTrace is very much like that. Deploy your software to test, turn on IntelliTrace and a log file will be generated. That file is your telemetry data. Using that file enables you to recreate what happened to your application. If you find yourself having to write a lot of Trace statements to understand why certain errors are happening you are going to love this.
So what else is IntelliTrace like. Remember the Tom Cruise movie Minority Report. Stay with me here. Tom Cruise used his hands to interact with data coming from psychic err something's. I am not talking about the flipping the hands to load a new scene, but how he actually goes backwards. He uses an imaginary dial and twists his hands left and right to go backwards and replay a scene. Well whilst you are developing code IntelliTrace is exactly like that. How many times have you gone through this cycle.
And it could be worse, you could be manually updating variables, skipping statements etc., so starting again from the first step could be a big waste of time. This is where IntelliTrace comes in. You can use IntelliTrace to go back through the debug session to find the part you need. How useful would that be? You can examine the call stack, local variable values and return values from functions. So that cycle above should now be a thing of the past.
Excited, interested, not bored yet. Excellent. See you in Part 2.
There seems to be so much coming out of Microsoft at the moment that it’s hard to keep up. One thing that you might have missed is WebMatrix.
WebMatrix is a lightweight IDE for building websites. It uses the Razor View Engine to make pages and the sites can be expanded to use full ASP.NET MVC later if required. It has a rock star package manager process (more on this later) and has some nice things out of the box like SEO hints.
There is a gallery with asp.net and Php (did i mention that you can build Php sites?) applications like Twitter helpers, BlogEngine.Net etc. It also ships with some basic templates like a store application.
So what’s different? Well the data access is well data access. No ORM, no config, no plumbing just access your data. It kind of feels nice to write queries again.
Rob Conery has a great write up of WebMatrix here. Here is a quote from Rob
var db = Database.Open("TDL");
var selectQueryString ="SELECT * FROM Articles";
shows = db.Query(selectQueryString, slug);Hooray for SQL! OK stay with me – what this returns is IEnumerable < dynamic >. Which means that it’s typed on the fly – DUCK FRICKIN TYPING. Well sort of. I can now loop this comme ca:
@foreach(var showinshows){
The title is@show.title
}That’s Razor in action – a terse, easy to love and understand markup for working in WebMatrix. The point here is that “show.Title” shouldn’t exist – “Show” isn’t a class anywhere in my project. This is the Groovy Dynamic Freakshow that’s built into C# 4.0.
You also get built in tooling for SQL CE (file based) which is downloaded with WebMatrix.
When you 0pen WebMatrix, you will see the box below
Choose templates and Starter site, give your site a name
Click Files
and open the Styles and css file and you will see the designer. It’s a little bit “I know that you are not a serious dev so I have made the font large and friendly” but stay with it. Have a look around it should be familiar
Package Mgr
Add an _admin to the end of your url when running in a browser and the package manager will appear
Once you have entered your password you can see what packages that you have installed. Here are mine
Change the dropdown to online and you will see
all of the packages that you can download!
Anyway I am just getting started – more to come!
Download it now and give it a try – Download WebMatrix
