Mark’s Testblog

I’ve been faffing around with Castle.DynamicProxy2 a bit lately and it’s a pretty interesting bit of kit.  Castle Dynamic Proxy (CDP) allows you to dynamically generate proxies at runtime to weave aspects of behaviour into existing types.  Aspect oriented programming is typically employed for implementing crosscutting concerns such as logging, performance measuring, raising INotifyPropertyChanged and various other types of repetitive and/or orthogonal concerns.  I’m a newbie to this stuff so I won’t say much more on AOP.

While I really like CDP, I’ve found that the documentation and tutorials (the best of which is Krzysztof Koźmic‘s excellent tutorial series) aren’t particularly explicit on how CDP achieves its effects, and sometimes these details are important.

There are two main ways of creating proxies that most developers will encounter.

CreateClassProxy

This is nearly always the first demonstrated method in tutorials.  ProxyGenerator.CreateClassProxy dynamically subclasses the target class, so if you have a class named Pogo and you call ProxyGenerator.CreateClassProxy, what you’ll get back is an instance of a subclass of Pogo (i.e. the new type is-a Pogo) that weaves in the interception behaviour via overriding methods.  This is why it is a stipulation that methods / properties must be virtual when they’re intercepted.

With class based interceptors, you cannot intercept non virtual methods because unlike Java, C# does not make methods virtual by default.  If you try to intercept a non-virtual method, nothing will happen, though mechanisms do exist to allow you to identify these situations and warn the developer (the most common example of this is that NHibernate will die on its arse if you try to use lazy loading with a non-virtual member).

CreateInterfaceProxyWithTarget

The second method is ProxyGenerator.CreateInterfaceProxyWithTarget, and it is the primary reason for writing this blog post!  CreateInterfaceProxyWithTarget does not dynamically subclass target types, it simply creates a dynamically generated class, implements the same target interface and then passes through to it.  I.e. it’s an implementation of the decorator pattern.  This has two effects, one of which is very important!

1. You don’t need to mark your methods/properties as virtual
2. Since it is a proxy working via decoration rather than subclassing, for the effects of the interceptor to be applied, all calls must be made on the proxy instance.  Think about it.

The most salient point is #2.  I’ll elaborate.

A worked example: Rocky Balboa

Say you have an interface called IBoxer like this:

… and you implement it like this:

If you then turn to aspect oriented programming and decide to gather statistics on punches thrown for the duration of a boxing round, it’s a reasonable assumption that you can simply proxy the IBoxer interface and intercept only the StraightLeft/StraightRight punch calls, tally them up and report the metrics (ignore whether this is a good idea to be doing this, it’s a contrived example).  On the face of it this isn’t a horrible idea.  However, it won’t work as expected.

The key here is that OneTwo() calls through to StraightLeft() and StraightRight().  Once the proxy has delegated to the decorated type it loses the ability to intercept the calls.  We can follow the call graph easily enough.  We have a reference to the proxy via the IBoxer interface.   We call “OneTwo()” on it and when the invocation proceeds, it delegates to the decorated Rocky instance.  The Rocky instance then calls StraightLeft(), StraightRight().  Both of these calls will immediately go straight to the ‘real’ implementation, bypassing the proxy.

Just as with the normal decorator pattern, the decorator (the IBoxer dynamic proxy in this case) loses its influence when the decorated object calls methods declared in its own public interface.  In this particular situation we could write an interceptor that knows to add two punches when OneTwo() is called on the proxy, but compare this approach to one using class based proxy.  If we were using a class proxy we could rest safe in the knowledge that all calls to StraightLeft() and StraightRight() will always be intercepted, as the extra stuff we’ve bolted on resides in a method override.

The results vary depending on the type of proxy we generate and the way the types are written. In hindsight it’s pretty obvious, but it still caught me out.

I was given an NDepend license to play around with (thanks to Patrick) and said I’d blog about it.  Apologies for my tardiness!

What is NDepend?

NDepend is a piece of software that allows developers to analyse and visualise their code in many interesting ways.  Here’s an ancient relic from my hard drive, revived in NDepend:

As you can see, there’s quite a lot of functionality included.  NDepend includes features that allow you to trawl your code for quality problems, identify architectural constraints that have been breached, find untested, complicated code or pinpoint changes between builds and much more.  This post will merely scratch the surface, but will hopefully provide some decent information on what NDepend can do for you and your team.

NDepend works with Visual Studio solution files and integrates with Visual Studio, meaning it’s simple to generate an NDepend project based on a solution.  You can then press the analyse button and watch NDepend do its thing — it generates a nice HTML report with various visualisations and statistics.

CQL all the way

NDepend provide a lot of pre-defined metrics out of the box, but its best feature by far (and the one on which most of its functionality is built) is the CQL query language.  The SQL / Linq-esque query language allows you to search, filter and order data in a simple fashion.  Once you get accustomed to the query language, it is simple to start bashing out meaningful queries.

You enter queries into a command window and the results are displayed instantly.  For example, you could write something like this:

At the time of writing, 82 separate metrics are available; the metrics are grouped by categories including: assembly, namespace, method etc.  If you have an idea, then you can probably express that idea via CQL.   Furthermore, your queries can be saved and reused/applied to projects as required.

To write a query, you just tap it into the query editor:

Don’t be Paralysed by Choice

While it is a hugely powerful program, I found it overwhelming to begin with.  The default analysis of your code will result in a verbose report including every metric under the sun; some of these are unarguably very useful (Cyclomatic complexity, IL nesting depth) whereas others have a more narrow purpose (suggesting which attributes should be sealed, boxing and unboxing warnings and so on).

Due to the mammoth amount of information in the report, it’s akin to pulling the FxCop lever for the first time.  You get metrics-shotgunned in the face and potentially paralysed by choice.  As a result, I chose to view the default report as a rough guide for how to use the CQL query language and to give me ideas of how I could form queries that were tailored to my needs.  There’s an excellent placemat PDF available for download, too.

I would encourage first time users to skim the main report for interesting nuggets then immediately begin to play around with the CQL query language :).  It’s really cool to think, “I wonder if…”, type a few words and immediately see the question answered.

Manual trawling versus NDepend

Back when I was a Test Engineer, I was assigned to look at an unfamiliar part of our codebase.  I decided to do a little experiment using NDepend to determine its effectiveness (we have a few licenses at work too and are looking to integrate it into our build process at some stage soon).  The test was simply this:  I would work through the code manually checking each file/type for problems, then I would do a sweep using NDepend to see if it could pick out the same problems (and potentially some others I’d missed).

The sort of things I was looking for included:

• Big balls of mud / God classes
• Types with the most complicated functionality (high cyclomatic complexity / code nesting level)
• Types that are heavily used (‘arteries’ of the codebase — failure would be more costly)
• Types that have poor coverage and high complexity

The results were good.  The majority of the problems I had identified during a manual sweep showed up near the top of the query results. It took me a few hours to manually trawl a relatively small portion of the codebase.  It took me about an hour to get to grips with the NDepend basics, write some CQL and make sense of the results.  I’d say that’s very good going considering I hadn’t used it before.

One thing to watch out for is that some manual tweaking is often required as, if you have some ugly utility classes or use open source software in source form (such as the command line argument parser class that is ubiquitous at work), these sorts of thing monopolise the results.  To get around this problem you can ignore these types, either by applying attributes to your types in code, or by adding an explicit exclude via your query (some examples of which are included below).

Sample Queries

Here’s a few examples of how to express the aforementioned concerns as queries.  Note: I’m an NDepend newbie, so there’s probably better ways to do this.

Types that have so many lines of code that it makes your head spin

Complicated nesting

Complicated methods

High complexity with poor test coverage

‘Popular’ types with poor test coverage

None of these are ‘hard’ rules — you have to play around with them while browsing your codebase (which is easy as NDepend’s CQL editor is constantly updating as you enter the query).  You may find that one project has really simple code that doesn’t even register on a solution-wide analysis, whereas another project may hog the results pane.  If you have a specific goal in mind, you can iteratively tailor the query to get what you want :).

The role of NDepend?

NDepend is not a silver bullet and doesn’t claim to be — it’s a complementary tool that can be used in addition to buddy systems, code reviews and so forth.  Having said that, the amount of information you can mine from your codebase is pretty impressive.

In terms of practical usage, we plan to integrate it into our build system to aid us in identifying potential problems, including code changes not backed by tests, architectural rules (project x is not allowed to reference project y) and general rules of thumb that should be respected (cyclomatic complexity, nesting depth and so forth).

In short, it’s well worth checking out NDepend.

As a test engineer, I spend a lot of my time reading –and making sense of– other people’s code.  I find it interesting that logically equivalent, re-arranged code can be much more easily understood.  Some of this follows on from the layout / style guide in the excellent Code Complete.  Perhaps I have unknowingly assimilated these idioms from reading, understanding and ultimately copying the layout of ‘good’ code.  Either way, they’re useful from a testing point of view, as it’s simpler to reason about code that doesn’t jump around so much.

As has been stated many times before, in general, the best programmers are the ones who program around the limitations of the human brain.  E.g. splitting a method into self documented sub methods, reducing nesting depth, reducing number of exits from a loop, grouping related logical statements and so forth.

Along similar lines, here’s a very simple but effective one: something I like to call “flattening“.

Reduce nesting by inverting logical statements

It’s a fairly simple concept.  By flipping a logical test or statement, you change the layout of the code, but the result remains the same.  Compare the two following two snippets:

Approach One

if(someVal != null)
{
   if(someOtherVal != null)
   {
       DoSomeStuff();

       //... 10 years later
       if(someOtherCondition)
       {
           DoExtraStuff();
       }
   }
}

Approach Two

if(someVal == null)
    return;

if(someOtherVal == null)
    return;

DoSomeStuff();
//... 10 years later
if(someOtherCondition)
{
    DoExtraStuff();
}

Even with these trivial examples, I think the first one is much more convoluted and harder to follow.  If invariants must hold at the start of a method, it makes much more sense to check them and return / return an error / throw an exception (as appropriate).  If multiple nested if statements are used from the start, the nesting depth in the method is increased by default.  Any further indentations compound the problem and reduce clarity.

I’ve seen fairly large methods (multiple pages) that suffered from this kind of problem and it made the code much harder to follow, especially when non-trivial work was done towards the end or a value was set earlier and returned later.  By the time you scroll to the end to deal with the problems, you’ve forgotten what came before.

By contrast, the second method is much flatter.  It basically reads like: “if this is invalid, return.  Done.  If the other one is invalid, return.  Done.  OK, we have valid inputs, so forget the validation phase and get started with the real work”.  It’s like removing a couple of juggling balls from the air — it removes a mental burden because you can simply ignore the initial checking logic.

You can also do things like introduce the continue keyword in loops and a few other things, but there are often caveats associated with such choices.

I use ‘flattening’ it in a lot of places, but there are occasions when it doesn’t make sense to flatten a method.  Sometimes it’s nicer to deal with the ‘standard’ case first regardless of the extra nesting depth.  In other scenarios, you can reduce nesting through the use of the continue keyword in loops, but lobbing a ‘continue’ keyword half way into a loop body adds a different kind of complexity, even if it means reduced nesting depth.

I.e. I like to use this a lot but, like most things, it shouldn’t be used indiscriminately.

Something I’ve just noticed is that Visual Studio falls far, far short when it comes to solution ordering.

Not only does it fail in an utterly abject fashion due to ordering things in an arbitrary fashion, but it doesn’t even allow you to drag things around and order them manually.  The end result is a frustrating experience, especially when you’re trying to make your solution neat, tidy and easily browsable.

I don’t understand why this is the case, because when you move projects around they are ordered alphabetically just fine.  Save, close and then re-open the solution and your projects will lose most of their ordering.

It’s akin to raking leaves into a neat pile then sitting back to admire your handy-work, only for Steve Ballmer to crash through your garden face, scrape the rake across your shins and then kick leaves in your face while bellowing “WOOOOOOO YEAH!”.

Well not really, but still.  It’s annoying.

Success

Here’s one I just created.  It looks grand.  Everything is ordered just as it should be.

Success!

Failure

Here’s the same solution after it has been closed and re-opened.

Fail!

The ordering is FUBAR.  There’s an issue on Microsoft’s VS product feedback page about this and it was duly ignored by the looks of things :(

How can something so simple not just, well, work?  Anyone know of any workarounds to enforce ordering?