Respect your test code #1: Hide object instantiation behind methods with meaningful names

Posted on by mookid8000 1 Comment

One thing, that I find really annoying, is that somehow it seems to be accepted that test code creates instances of this and that like crazy! In a system I am currently maintaining with about 1MLOC where ~40% is test code, I often come across test fixtures with something like 20 individual tests, and each and every one of them creates instances of maybe 5 different entities, builds an object graph, runs some code to be tested, and does some assertions on the result.

This is a super example on how to write brittle and rigid tests, because what happens if the signature of one of the ctors changes? Or the semantics of the object graph? Or [insert way too many ways for the test to break for the wrong reasons here…].

When I come across these tests, I usually factor out the creation of all but the most simple objects behind methods with meaningful names. This has two advantages: 1) It’s more DRY because they can be re-used, and 2) It serves as brilliant documentation. Consider this rather simple assertion that requires a few objects to be in place:

compared to this:

MUCH more clear! The factory method acts as brilliant documentation on which aspects of the test are relevant to the outcome – it is clear, that a mortgage deed which has not yet begun its amortization must report its first term date as the actual principal date.

Go on to test another property of the mortgage deed before amortization:

– and we have already saved us from writing 50 lines of brittle rigid test code. Keep factoring out common stuff, so that the ctor of the mortage deed is still only called in one place… e.g. create methods like this:

which allows me to write cute easy-to-understand tests like this:

This is also a good example on how to avoid writing // bla bla comments all over the place – it’s just not necessary when the methods have sufficiently well-describing names.

Working with Windsor and ASP.NET MVC

Posted on by mookid8000 1 Comment

In the previous post I showed how easy it is to install an IoC container at the system boundary of your ASP.NET MVC application and have it resolve everything from there.

But what I did not show, was where the container came from – in the example, the container just pops out of nowhere on this line:

So how can we implement GetContainerInstanceFromSomewhere()?

Well, I like to do it like this:

Isn’t that easy? And then I have a folder structure in my ASP.NET MVC project that looks like this:

config-folder

It can be seen that I have a folder for each configuration of the system (development, test, prod) and one containing configuration files that are common for all configurations. For each configuration I have a hibernate.cfg.xml to configure NHibernate and a windsor.config which is loaded by the Windsor container in each particular configuration.

My development/windsor.config looks like this:

It can be seen that my development configuration is used to Cassini running on port 1766 🙂 moreover, it can be seen that my development configuration is using a fake, logging email sender, which – much as you would expect – only logs the content from emails that would otherwise have been sent.

Of course, the configuration files will not automatically be available to the web application the way they are organized now – therefore, my web project has a post-build task with the following two lines:

– thus copying the common configuration files along with the development configuration files to the base directory of the web application.

This also means that my build script must overwrite the development configuration files when building the system in a deployment configuration. It can be achieved as simple as this (using MSBuild):

Here I have define tasks for compiling the web site (“build”), deploying the binaries + views + content files (“deploy”), deploying common configuration files (“deploy_common_configuration_files”), and then one task for each deployable configuration: “deploy_test” and “deploy_prod”. This makes deploying the web site on my test web server as easy as running the following command:

What is left now, is to make sure that the different sets of configuration files are valid in the sense that Windsor can resolve everything right. That is easily accomplished in the following NUnit test:

This way, if I introduce a service in my development configuration that should have been implemented by a production version of the service in my production configuration, I will immediately know about it.

I think this post covers an easy and pragmatic way to control multiple configurations with Windsor and ASP.NET MVC. Of course you might want to split out the configuration-specific parts into multiple files instead of having only a windsor.config for each configuration. What I mean is something like this:

The great thing is that we can refactor our configuration with confidence because of our test. And if we want to be extra-certain that everything works as expect, we might begin to add assertions like this:

Playing around with the visitor pattern

Posted on by mookid8000 Leave a comment

I have been thinking a little bit about the visitor pattern recently. One of my most recent applications was in combination with a class, which would be used in a message distribution scenario.

The class’ reposibility is – given a list of email addresses – to look up any existing users in my application, and allow the caller to perform an action depending on whether the email belongs to a registered user or not. Pretty simple if you feel like juggling dictionaries and stuff, but I made an even simpler solution.

My email lookup service has the following interface:

And then I have two classes: EmailRecipient and UserRecipient which are both specializations of the abstract superclass Recipient – each containing either an email (a string) or an IUser depending on whether the service was able to look up a user.

Then I have another service, which functions as a message distributor. Given a list of email addresses, either an email or an internal message will be delivered to each recipient. This is a perfect application for the visitor pattern, because it allows us to avoid this kind of brittle code:

I have seen this kind of code in far too many places where inheritance is used. It is obviously very brittle, because what happens if someone adds another kind of Recipient? Nothing at first, because the code will compile like everything is allright. Only after the code is run, and we actually get in a situation where another kind of Recipient is encountered, do we get an error… and in the example above, I was courteous and threw an exception – but what if the original author had not done that? The program could have been silently failing for months before someone found out… yikes!

Another solution is to move the behavior into the specializations – e.g. into an implementation of an abstract SendMessage method on Recipient. But then the specializations would require a reference to either the emailService or the messageService, which would kind of turn the layering upside down, since the domain classes would need to know about some higher level services.

What we really want, is for a service to be able to behave differently depending on which specialization is encountered, and for that service to contain the logic to handle each specialization. And we want errors at compile-time if a specialization is not handled. Enter the visitor pattern…

One way to accomplish this is by using the visitor pattern as described by GoF. It’s pretty simple: Make a call to an abstract method which gets implemented by each specialization, and let that specialization make a suitable callback to identify itself. My visitor interface looks like this:

– and then each specialization must implement the abstract Visit method from the Recipient class:

and then invoke their correponding callback method passing themselves back.

Then my client can create an implementation of IRecipientVisitor, supplying it with the necessary services, allowing the visitor to do different stuff depending on the specializations. But that requires me to implement a class like this every time I have a reason to do different stuff:

Having done this a few times, implementing a new class each time which would be used only once, I started thinking about how to accomplish this with fewer lines of code. One thing that really bugged me, was that I needed to supply the visitor with all kinds of context data to allow the visitor to perform whichever action it would decide to carry out, depending on which Visit(...) method would be called. Then I came up with the generic visitor:

Now my message dispatch can be implemented like this:

Why is this great?

1. I get to implement multiple dispatch with all the safety of the visitor pattern. If I add a new specialization of Recipient, e.g. ErronousEmailRecipient, I add a new method to the IRecipientVisitor interface. That causes the RecipientVisitor to break, so I implement the new method in there as well, in turn causing the code to break everywhere the visitor is used (“break” in a good not introducing bugs-kind-of-way). That way I can be sure that I will know where to handle this new specialization.

2. I get access to the context I am already in. Instead of creating a new visitor and supplying it with sufficient context to carry out whichever actions it needs to perform, I can specify in a short and concise way what I want to do for each specialization, accessing any local variables inside of the scope my labdas are in. That’s just elegant and easy.

3. The code is where it is used. The distance from usage to implementation is zero. Of course, if the implementation is more complex, it may look more like so:

– which is still pretty terse and to-the-point compared to creating an entirely new dedicated class for this.

How JavaScript’s closures surprised me

Posted on by mookid8000 Leave a comment

Well, it happened when I was making a web page on which the user could pick a number of time slots. The time slots would be configured using a calendar and a couple of time entry controls, and the user would add the time slot by clicking a button. The selected time slots would be stored as a JSON serialized array of time slots in an input element.

The selected time slots would be shown in a list on the page, each one with an X on the side which could be used to remove the appropriate time slot. The problem was, that it did not remove the appropriate time slot. But why?

It’s because of the way JavaScript’s closures are implemented!

You see, my code was something like this (using Crockford’s JSON library and the incredible jQuery):

What happened when I tried to remove the time slots? The most recently added time slot would get removed all the time, even though I clicked the first and the second etc.

At this point, I knew it was due to some JavaScript function closure stuff, because I could see that my click event handler would call removeTimeSlot with the id of the most recently added time slot all the time.

But why was this happening? I made all kind of changes to the snippet, moved the variables around, made several temporary variables, but the problem persisted!

Then I searched around, and I discovered two things that I did not know about JavaScript (and would not have expected):

  1. Variables reside in the function in which they are declared.
  2. Functions get the closure of their containing function.

I am a C# guy, and in C# I know that an anonymous delegate gets the closure that it needs and nothing more. I also know that variables declared inside the scope of for instance a for loop are local to that loop. So doing stuff like this would not cause any unexpected behaviour:

To put it another way, it means that my code was actually equivalent to this (notice how all my variabled are “declared” at the top of the function):

To circumvent this, I created an inline function which would deliver the DOM element with the link. Something like this:

– and from now on, to avoid unnecessary confusion, I will stop declaring my variables anywhere except the beginning of each function.

Lastly, I would like to give some shoutouts to the Mozilla folks for driving us all forward. Firefox 2 actually implements JavaScript 1.7, in which let was introduced as a keyword. let creates a new lexical scope and fixes one or more variables, which will then be promoted to a closure if necessary. Using let, my code would look like this:

– which is a lot simpler than the inline function version I ended up using. However, JavaScript 1.7 is not implemented by other browsers than Firefox 2 and Safari 3.x (according to Wikipedia) so it’s not really an option yet.

Way more nifty: Using compression at field level when persisting #2

Posted on by mookid8000 Leave a comment

In a previous post (here) I showed how the contents of a string property could be internally stored as a GZipped byte array for persistence. The code demonstrated how to achieve this, but not in a particularly pretty manner, because I did some nasty hacks inside the property’s setter and getter – i.e. I crammed all the zipping/unzipping stuff directly inside my domain class.

When using NHibernate for persistence you have another option, which I have recently learned about. So let’s rewrite the example from my previous post.
Read more

Mocking IEnumerable and IEnumerator with NMock2

Posted on by mookid8000 2 Comments

Edit: This post is actually about a weird NMock error message. As Nigel Thorne so kindly pointed out, this way of testing an IEnumerable is kind of awkward and cumbersome, as I should have just done something like this:

Please use this approach, unless your test subject is actually the implementation of the foreach construct 😉

Original post:
A recent problem I had was when I attempted to mock a function returning an IEnumerable<T>. I went about and punched in somthing that I expected to work – something like this:

– and then I set some expectations on the usage:

– and the usage inside my class under test was something like this:

– but then I ran the test, and I got this cryptic error message:

This was really annoying! Especially due to the fact that the foreach prevented me from seeing what was actually going on. It took me a few minutes to realize that the error came from me being too sloppy to check out the IEnumerator interface I was mocking – the interface looks like this:

(where the generic IEnumerator<T> interface inherits from IEnumerator, narrowing the return type of the Current property down to objects of type T).

Can you spot the error?

The return type of MoveNext is bool!!!

When I am mocking a method call like this:

NMock will check the method signature – and if the signature has a return type other than void, NMock tries to be nice and – instead of emitting an error (which IMO would be appropriate) – returns null! And since null is a reference type, but the expected type was bool, I got the cryptic RemotingException.

The solution was obvious:

PS: I am posting this to avoid having this problem again (for too long). I remember having had this error before, but it took me almost 30 minutes to realize what was wrong. Hopefully, next time I will remember 🙂

Tailoring a custom matcher for NMock

Posted on by mookid8000 2 Comments

You’ll often hear proponents of test-driven development claim that unit testing is hard and that it forces them to open up their classes’ hidden logic for them to be testable. That might be true to some degree, but more often in my opinion you’ll find that designing your system to be testable also has the nifty side-effect of separating your logic into .. umm logical chunks… and what I really mean here is that your chunks have a tendency to become orthogonal, which is by far one of the best quality attributes of a system.

BUT that was not what I was going to say, actually – I just wanted to comment on a nifty thing, I recently found out: implementing my own Matcher to use with NMock.

An NMock Matcher is an abstract class, which requires you to implement the following members:

A matcher can be used in the call to With(...) when stubbing or expecting… an example could be setting an expectation that a search function on our user repository will return an empty result… like so:

In the example above, Is is a class containing a static method StringContatining, which returns a matcher of a certain type. Now, when the test runs, and NMock needs to decide if an intercepted function call matches the expectation above, it will iterate though the given matchers, and call their Matches function, passing to it the actual argument as object o.

The matcher returned by StringContaining probably contains an implementation of Matches which looks something like this:

where _substring was probably set in the ctor of the matcher when it was constructed by the StringContaining function.

Now that leads me to my recent problem: I needed to pull out the actual argument given when the expected function call was performed. In my case the argument was a delegate, which I wanted to pull out, and then invoke it a few times with different arguments.

What I did was this:

This allows me to set up an expectation like this:

Now, after the code has been run, I have access to the delegate passed to the file service through snatcher.Object.

If someone knows a cooler way to do this, please do post a comment below. Until then, I will continue to think that it was actually pretty nifty.

How to configure NHaml

Posted on by mookid8000 Leave a comment

Ever wanted to use your own custom HtmlHelper extensions inside your NHaml views? I wanted that, but I got this error:

error CS1061: ‘System.Web.Mvc.HtmlHelper’ does not contain a definition for ‘WhyOhWhy’ and no extension method ‘WhyOhWhy’ accepting a first argument of type ‘System.Web.Mvc.HtmlHelper’ could be found (are you missing a using directive or an assembly reference?)

The problem was that NHaml would not know that there existed some extensions of the HtmlHelper class in some obscure assembly somewhere inside my web app. To do this, you need to tell NHaml exactly which assembly and which namespaces to include in its search. Here is how to do it:

In your web.config, beneath the <configSections> node, add this

– and then outside of <configSections>, add this:

This will cause NHaml.config to be included. We could just have embedded the configuration inside the web.config file, but we want to make separate NHaml.config files for each environment we want to deploy our application in. Then we can turn on NHaml’s compiled view caching feature by flicking the production attribute.

An example NHaml configuration is something like this:

Suddenly you will gain access to everything inside the specified namespaces inside your NHaml templates. Nifty!

Using compression at field level when persisting

Posted on by mookid8000 1 Comment

One day at work, someone needed to store a lot of text in a field of a domain object – and since we are using NHibernate for persistence, that field would get stored to the database, taking up a huge amount of space.

To circumvent this, we just made the actual type of the member variable description be a byte[], and then we let the accessor property Description zip and unzip when accessing the value.

Like so:

It should be noted that it is crucial that the ToArray() method of the compressed MemoryStream be called after the GZipStream stream has been disposed! That’s because the GZipStream will not write the gzip stream footer bytes until the stream is disposed. So if ToArray() is called before disposing, you will get an incomplete stream of bytes.

Moreover it should be noted that zipping strings in the database is not always cool because:

  1. Compression kicks in for strings at around 2-300 chars. The size of the compressed data is greater than that of the original string for shorter strings.
  2. Querying is impossible/hard/weird. 🙂

But it is a nifty little trick to put in one’s backpack, and I had all sorts of trouble figuring out exactly how to make the GZipStream behave, so I figured it would be nice to put a working example on the net.

Nifty web site with ASP.NET MVC

Posted on by mookid8000 1 Comment

Sorry about the delay – I was interrupted by the new ASP.NET MVC release CTP 2 which came out last Wednesday or Thursday or something… I am currently working on updating the series to use CTP 2 instead of the first one… please be patient 🙂

Update: Sorry, but I cancelled this series again. There so many tutorials on how to get going with ASP.NET MVC out there, so I will not finish this series. You should definitely check out Kazi Manzur Rashid’s blog – e.g. his two posts on best practices are brilliant: part 1 & part 2, and he has written a lot of other interesting stuff as well.