The first C# tool that I’ve been looking at is NCover, a very popular piece of software intended to do static code analysis and integrate with a build system.  NCover primarily focuses on calculating unit test coverage and cyclomatic complexity, two undeniably good metrics to drive test driven development and build maintainable code.  NCover has an analysis tool called NCover Explorer, which allows you to view the results of the test run, reports and visualizations on each execution, and trending when analyzing multiple test runs.

The Good

NCover is easy to set up and integrates as an external tool in Visual Studio, which makes kicking off the process of code analysis easy.  The Explorer allows some fairly flexible views of each code execution, which lines of code are not covered, and cyclomatic complexity at each method level.  This is also configurable so you can few complexity on each branch or symbol, but I’ve not messed with that much yet.  NCover allows you to exclude certain assemblies and provides roll-ups and reports of your coverage and what has changed in between runs.  I find this valuable in my daily work, and these reports also integrate with build systems (which I should get to play with relatively soon.)

The Bad

The structure of your unit test solutions matter.  We have a large codebase with a large set of unit tests, so it takes several minutes for the NCover report to run.  There is some strangeness with the External Tool configuration as well, it requires you to have your Unit Test project highlighted or else it can’t kick off the assembly correctly and errors. The way that trending is handled is clunky and not as useful in the Explorer as they would hope.  Our solution gets incremental improvements in each class, and the resolution of the graph on the NCover Explorer is not as helpful.  Also, the trend analysis counts failed runs as zero coverage which really makes the trending less useful if you accidentally fat finger the External Tool or don’t highlight the project properly.

The searching capabilities within the Explorer are clunky and take too long to execute, and the reports are a bit difficult to comprehend.  This could just be a limitation of my ability to interpret them though.  I don’t know if there’s a plug-in for Visual Studio to provide in-IDE highlighting of uncovered lines of code, I will have to look into this further.  It would be nice if this exists, since I know other tools provide this feature.

More on this soon, I suspect I will have more write once I try to integrate this with a build server and explore the features more closely.

Today was a good one at the office, I got caught up with some loose ends that have been trailing since last week.  This allowed me to participate in some discussions on code quality and how to enforce it in our organization, which is going to require me to research testing enforcement, code equality, and code coverage tools for C#.  I know of several good ones, and I’m finding out more and more about others as time goes on.  I might do a wrap-up of these tools once I’ve gotten a chance to play with them a little bit.

I really enjoy learning more about code quality and how it can be best applied to coding teams of our size.  This should make for some interesting research.  That’s all I’ve got for now, maybe some results will come along in the next week or two.

Over the weekend, I inherited some unit test code.  This code was functional, but it was my job to inspect it to ensure that we had appropriate coverage.  It covered a pretty broad spectrum, so after 10 hours of inspecting the code carefully I had come up with some observations that later led me to these handy unit testing guidelines.

When designing unit tests, ask yourself the following questions:

1. Is my test setup concise, clear, and flexible?
2. At a glance, is it clear what this unit test is actually testing?
3. Am I asserting the proper results apply for all relevant fields?

Let’s look at these questions in further detail to understand better:

Is my test setup concise, clear, and flexible?

The root of this question lies in lazy coding versus intentional coding.  The code that I happened to be testing relied heavily on certain classes and did not have an overloaded constructor.  This forced what should have been a 1-2 line constructor to build the object into a 10-15 line long block of setting arguments for the class after it had been created.  To make matters worse, most of the code was using the same parameters each time the object was created, which just begged for refactoring.  We spend a lot of time in our unit test code, in some cases MORE time than our actual production code (especially if you are practicing Test Driven Development) so you owe it to yourself to write concise, clean, and readable code.  If not for you, then for the next poor schmo that has to read your code later.

By ensuring you have proper constructors and helper methods to make your default objects and allow setting of arguments, you don’t pull focus from what the unit test is actually doing by hiding it’s value in tens to hundreds of lines of test setup.  In practice, I find myself questioning if my setup is concise enough if it extends much beyond 10 lines of preamble before I call the method I am testing.  This leads nicely into my second point:

At a glance, is it clear what my unit test is actually testing?

Unit tests should either test a specific method’s output, or a specific business scenario.  In both cases, you don’t want the actual method you are testing to be hidden amidst tens to hundreds of lines of setup.  If you have that much setup, you need a helper class to enable quick setup of the objects and values that you need to test your method especially if you’re planning on doing more than one test or your QA team hasn’t gotten hold of the feature yet. (I could go on a rant here about test driven development and why it is important, but that topic is for another time).

Am I asserting the proper results apply for all relevant fields?

Last, but certainly not least, it is important never to lose sight of what a unit test is meant to do: assert, assert, assert.  If you are testing an object, it does not hurt to assert each value that is relevant to the method that you are testing.  Often times, it is easy to assume that another unit test somewhere else in the codebase is testing that field but I have found that often there is less coverage than expected.  Spend the extra few lines and assert all of the return values in an object, especially if the case took a considerable amount of setup code to get rolling.

In this same vein, also be careful to think about scenarios how your code will be invoked or used.  Often, unit tests do a good job of testing the individual puzzle pieces that make up your implementation, but sometimes if fit together incorrectly the feature still does not work properly.  In our group,  I recommend a combination of traditional unit level tests with more “functional units” that exercise the workflow to ensure that the piece of code I am testing plays well with the other bits of code around it.  A good example is testing a method directly and then testing the client service that wraps it into a feature to ensure that the proper values are returned in both cases.

So that’s it!  Three simple steps that help you toward writing better unit tests.  If you find this type of thing interesting, let me know in the comments and I will write more!

I have been in a foul mood in the office this week.  There are many contributing factors, most of all continued pressure late in our development cycle.  Without going into too much detail, suffice it to say that I am Busy.  With a capital B.

I have heard about the development approach of having the entire team get into a room together and code/test/fix things and we actually tried it with this release.  Today, since we were starting a new user story (late) I opted to do this once again and I was amazed at how productive I was.  In fact, I might have a run at pulling off the impossible and getting things done in time for the end of Friday!

I actually love coding.  I love designing as well.  What I don’t like is doing either while under extreme pressure to deliver.  I could now vent for a long time about how processes fit into this space, but I don’t feel like putting up a 2,000 word essay on the topic tonight.

I will leave it at this: if you leave a nerd to code, he will code.  Most times, he will code for what appears to be a ridiculous amount of time without sustenance or other human interaction.  If you add to this a neverending batch of ultra-high priority items, said nerd will code until he is a withered skeleton with no social skills and eventually you will be staffing another role because he slumped over at his desk one day.  Also, accusing that skeleton of not producing enough only makes you look stupid.

I don’t know why this is difficult for management to understand.  Maybe one day I will, but that day will not be today.

At work, I had to do battle with a particularly annoying set of bugs.  These were the type of bugs where everything looked like it was working properly and just wasn’t functioning correctly.  After beating my head against the table all day, getting frustrated and fed up, having some Chick-fil-A, I eventually had an “a-ha!” moment and was able to solve the problem.

Since the “a-ha!” came at 2 pm, I was busting my butt to get the code done, tested, and checked in prior to being out of the office until Thursday of next week but I got it done.  I even did more testing than I normally would have done, because I don’t want to get called on my time off.

This was one of those moments where I only knew the fix because I had done this work before in the past, so it was a really nice feeling of accomplishment coupled with pride that I actually was the right person for this particular job.

So now it’s vacation time!!  Matt and Sarah show up on Sunday and I am definitely looking forward to it!

Today was a good day.  We had Agile training at work, where I learned a few new techniques and design patterns.  Shortly after I arrived at work, Tasha texted me to tell me that her iPad had arrived.  The rest of the workday completed without incident.  I came home extra-motivated from two days of learning stuff, so I did a few hours of work on one of my side jobs and then Tasha and I went to Chick-fil-A after she got home from D&D Encounters.

Since it was raining/snowing on the way home, I decided that it would be a good night to burn our last fireplace log for the season and we whiled away the rest of the evening watching TV.  The Media Center had picked up a few Big Bang Theory episodes and my favorite Simpsons episode of all time: El Viaje Misterioso de Nuestro Jomer (The Mysterious Voyage of Our Homer).

A good day full of minor victories.  In your face, Space Coyote.

Work gave me a MSDN license, so I’m installing a fresh, awesome set of development tools.  I need more hard drive space on my laptop badly for situations such as this.  Visual Studio 2010 Ultimate, here I come!!  In addition, I’m going to install Windows 7 on my Eee PC so I can see how that handles.  It is hard to blog because my system resources are being taxed with multiple downloads and installations, so I will leave it here for the night!  Woohoo!

I woke up feeling like boiled crap this morning, I had a sore throat that was affecting one of my ears.  I wasn’t running a fever so I decided to go in, and I ended up having a pretty productive day today.

I’m slowly learning my way through C#, I had the opportunity to do a WinForms application to test the performance of one of our mapping vendors.  WinForms are pretty easy to learn, by the end of the day I had a pretty looking, semi-functional little application to play with.

I got to learn a little about ADO.NET data sources and OLE DB querying, I had an Excel spreadsheet with some data that I needed and I was able to get it loaded into a DataGrid using those technologies just fine.  Tomorrow I’ll finish wiring up that data and I think I can put that one to rest.

Because I was feeling bad today, I elected to delay training until tomorrow night.  More soon!

The first chapter of my C# book that I’m reading dealt with the .NET Framework, including high level details around the Common Language Runtime, Framework Class Library, Common Type System, and the Common Language Specification.  I found the Common Language Specification pretty interesting… simple interoperability between languages is a pretty neat concept and I’m eager to see it in action.

I suspect I’ll get into some actual coding practice later on this weekend… this book is somewhat light on introductory coding stuff, so I suspect I will be into new things shortly!

Tonight I cracked the spine on my new copy of C# 3.0 Unleashed with the .NET Frameworks 3.5.  Not much actual learning took place, but I did read through the introduction which lays out the flow of the book.  I should be able to blow through the first several sections quickly, I think I’ll get underway with the first actual chapter tomorrow night!