Being Cellfish

If it is hard to test, you did something wrong

Emil Gustafsson — Thu, 16 May 2013 12:16:00 GMT

I've often been asked questions like how would you test this or been told that there cannot be unit test for some code because it is impossible to test. Well, my opinion is that if something is hard to test it is all your fault. You designed it, you implemented it and hence it is your fault it is hard to test.

The situation in which people have the hardest time accepting that it is their own fault is when dealing with external dependencies. They say things like "I'm using this other module that does not provide a nice interface". And then they typically revert to some mocking framework to cleanup their mess. Most mocking frameworks today are powerful enough through reflection or even binary instrumentation that they magically can make untestable code very untestable.

Rather than using powerful tools as my savior, I use abstractions. Whenever I depend on something that is not easy to test and that I do not have the power to change I hide it behind an abstraction; an interface or just a class with a few virtual methods I can override in my tests. Is this abstraction just another level of indirection? I do not believe so. Isolating dependencies makes it possible for me to implement something the way I want it to be and then deal with the behavior of the dependency separately. Here is an example from real life:

I needed to implement a feature that depended on two components that really didn't lend them selves for easy faking. So I created two new interfaces representing the functionality I needed for my feature. As I started to integrate the first component it became clear that the interface I needed was not provided by the dependency in an easy way. I needed to put some logic in there to make it work the way my feature expected it. So I created a new interface representing the dependency functionality and made that a dependency of a class that added the logic needed to transform dependency results into what my feature needed. I did not expect this but it was easy given my design and the fact I did not know exactly how the dependency worked in the beginning did not stop me from being productive. My second dependency turned out to behave the way I expected and the interface I invented could easy be used to wrap the second dependency.

The key is that the wrapper for each external dependency should be thin. Preferably one-liners so there is no need to test them. That does not mean the method signature needs to be the same as your dependency. I often make my wrapper signature simpler than what the dependency actually needs.

And remember; if it is hard to test - You did something wrong!

Collection initializers not doing what you expect

Emil Gustafsson — Thu, 09 May 2013 12:09:00 GMT

Let's assume that you have a class that have a collection property and that you want the default for that collection to be to actually have a value. That class might look like this:

 1: class Foo
 2: {
 3:     public Foo()
 4:     {
 5:         this.Numbers = new List<int> { 4711 };
 6:     }
 7:     public ICollection<int> Numbers { get; set; }
 8: }

Now somewhere else in your code you want to override the collection value and set some other value so you do this:

 9: var foo= new Foo { Numbers = { 42 } };

So what is now the value of the property Numbers? Turns out it actually holds both the initial value and the new value rather than just the one value you want. The way to do it if you only want one value is this:

 9: var foo= new Foo { Numbers = new List<int> { 42 } };

One way to try and avoid this is to not initialize the Numbers property with a list but rather an array like this:

 5:         this.Numbers = new[] { 4711 };

But that might not always be possible so you might be better off by not exposing your collections like this and only provide an IEnumerable property for enumeration and do all manipulation through separate methods and not properties.

Task-based Asynchronous Pattern - kick starter

Emil Gustafsson — Thu, 02 May 2013 12:02:00 GMT

Regardless of if you are new to TAP (Task-based Asynchronous Pattern aka "async/await") or have been doing it for a while this presentation from an MVP summit in February (2013) serves both as a good introduction explaining how it works as well as providing deeper knowledge and high-lighting a few common problems. It's a short presentation so definitely worth downloading and reading!

How to know when the garbage collector is not helping you

Emil Gustafsson — Thu, 25 Apr 2013 11:25:00 GMT

A while back I did an experiment where it turned out that allocating objects was better than pooling them. Since then I have encountered a few times where allocating actually turned out to be a bad thing. I've never seen this being a problem in a client application, but in servers allocating a lot of objects can be a problem even if the objects are very short lived. What happened to me was that so many objects were created that the garbage collector wanted to run several times a second to try and clean things up. Each time a few of these short lived objects would escape from generation zero to generation one making any following garbage collections more expensive. This time I was lucky because the object in question was a byte array buffer that could be both reduced and reused with some simple logic.

What might be harder is when you add async/await and tasks into the mix. The reason is that async/await is very good at making your async code easy to understand but at the same time it can create a lot of objects if you just do the naive implementation of what you want to do. However the naive approach is still the preferred one I think since it reduces the risk of creating something that does not do what you want under all circumstances. But it is always good to know what is happening and that is why you should read this article that explains how to use the memory profiler and as an example look at an example with tasks.

Using T4 to eliminate maintenance

Emil Gustafsson — Thu, 18 Apr 2013 11:18:00 GMT

I like to abstract diagnostics (logging and performance counters) into a separate interface or abstract class. But it becomes tedious to manually keep the fake diagnostics (used to test that that proper diagnostics calls are made), dummy diagnostics (when I just need something to pass around), console loggers (used for command line applications) and production logging in sync with the interface. And it is boring to do manually since the first three essentially have the same implementation for all methods.

So what I've started to do is to use T4 to generate those three files but also the interface. Production logging is still updated manually but I think it is important to consider exactly what events and performance counters should be triggered by each event. And I want to keep my diagnostics definition simple. So this is what I do:

I created a include file in a common place (solution item) that defines some common classes to generate method declarations and method calls.
I created a include file in a common place (solution item) that defines my interface.
I created one template (where needed, typically in different projects) to generate the interface, fake, dummy and console logger.

I find it easy to work with the T4 template files (even though it feels a little like you're back to classical PHP/ASP style programing, but it does remove some boring tasks. And the error messages you get when you have errors in your template have been pretty good for me so it has been easy to correct the problems.

The only downside with this is that when you change the include file you need to transform the templates manually in visual studio. Unless you install an SDK that defines a build target you can use. This Is because the T4 transformation happens when the template file is saved, not when one of its dependencies change. I did however find this clever way of getting around it which is essentially running the tool manually as a build step. I prefer that over forcing additional SDKs to be installed by everyone including the build servers. I only hope this will be just working in a future version if VS.

Analyzing logs from Azure web sites

Emil Gustafsson — Thu, 11 Apr 2013 11:11:00 GMT

I recently played around with Azure web sites and wanted to analyze the IIS logs generated by azure but none of the tools I tried could parse the file I downloaded. Turned out that the header line of the file that looks like this:

# date time s-sitename cs-method ...

That is apparently not correct W3C log format. once I change the line to this:

#Fields: date time s-sitename cs-method ...

With that change all the tools I tried were happy with the log files.

Factory pattern improved

Emil Gustafsson — Mon, 01 Apr 2013 11:01:00 GMT

My impression of most major west coast cities like Seattle, San Francisco, Los Angeles etc, is that people in general are very healthy. And Redmond where Microsoft have its HQ is even the bicycle capital of the north west (I guess anything can be the capital of anything if you just constrain geography in a convenient way). And people who like to exercise also typically like to be environment friendly. And in the spirit to make applications more environmentally friendly there are a few new patterns you need to learn. I have been using these new patterns together with a co-worker for exactly one year now. The first pattern is a replacement for the polluting factory pattern; the farmers market pattern!

The farmers market pattern is similar to the factory pattern in that it is used to create other objects, but instead of having all the bad properties of a factory such as being far away from the object and not caring about the object's community. Factories also tend to keep the benefit they create for themselves. The farmers market pattern gives you a local object that can create your objects on a local and hence more environmentally friendly way. Here is what it looks like in it's most simple form:

 1: public class Foo
 2: {
 3:     private Foo()
 4:     {
 5:     }
 6:  
 7:     public static class FarmersMarket
 8:     {
 9:         public static Foo Create()
 10:         {
 11:             return new Foo();
 12:         }
 13:     }
 14: }

Having a the farmers market class local like this will save CPU cycles during compilation making sure your application is produced with minimal carbon dioxide footprint. Tomorrow I'll show you the hybrid pattern.

Using HTML as your web service format

Emil Gustafsson — Thu, 28 Mar 2013 10:28:00 GMT

In the past I've seen examples of clever use of style sheets to turn XML responses into browsable results that are human readable and more important; human navigable. But this was the first time I heard about using HTML straight up to create the content of a web service API. It is interesting that there is so much focus of defending HTML as shorter than JSON when I think size should not really be a factor here. Sure, mobile clients want smaller payload but with faster and faster networks and clients with more memory the availability of parser are far more important. but if we can assume that all client have both JSON and XML parsers that is not a deciding factor. I think the most important factor is what the client wants. The linked article mentions that using compressed payload is common and as such it is used as an argument why HTML is not really larger than JSON. But whether or not compression is used is something the clients requests in its request headers. Which content type a client can handled is also an HTTP header so I think it is a no-brainer for a web service to support multiple content types if needed by its clients. Supporting both XML and JSON should be trivial these days and implementing a HTML serializer should be trivial.

I also think the format the author used for HTML was a little bit surprising. My first thought was to convert the example JSON used into something like this:

<html><body>
<dl>
 <dt>contacts</dt>
 <dd><ol>
  <li><dt>firstname</dt><dd>Jon</dd><dt>lastname</dt><dd>Moore</dd></li>
  <li><dt>firstname</dt><dd>Homer</dd><dt>lastname</dt><dd>Simpson</dd></li>
 </ol></dd>
</dl>
</body></html>

That even turned out to be slightly smaller than what was suggested in the article. Not that size matters...

Analysing code coverage

Emil Gustafsson — Thu, 21 Mar 2013 13:21:00 GMT

I was recently asked to look at a project that had around 60% code coverage and was asked to give my recommendations on what area to focus on to increase the code coverage. There were a lot of unit tests and actually there was around 10% more unit test code than production code so I was a little surprised that the coverage was as low as 60%. Obviously something must be wrong with the tests. A closer look showed that the code that implemented the logic of the application had very high coverage in general and that only the code dealing with external dependencies had low coverage. Also there wasn't that much code so the boilerplate code just to initialize the application was around 15% of the code. The code dealing with external dependencies and that low coverage was slightly less than 10%. So all in all 60 of the possible 75% was covered. Relatively speaking that is 80% - a number I've often heard managers be very happy with (but remember code coverage itself is a shady property to measure).

So what was missing? Well there were a few cases where a few small classes completely were missing unit tests so they would be easy to fix. There were also a bunch of classes that had unit tests exclusively for the happy path of execution and those can be fixed easily too. But I still think it would be possible to bring coverage up above 90%. How is that possible you might think? Well, the boiler plate code had some, but more important the code dealing with external dependencies had a lot of room for improvement. They were much more than simple pass through objects needing no testing and with a simple refactoring like extracting the external call as a protected virtual method of the class you could easily add unit tests for a huge portion of that code to I think.

So my conclusion? The original coverage was not bad. It was covering the important pieces and functional tests (not used when I analysed code coverage) covered a big portion of the code not covered by unit tests. So the situation was not bad. But when you use a code coverage report the right way and look at what and why it is not covered you can always find areas of improvement.

Certificates are hard

Emil Gustafsson — Thu, 14 Mar 2013 14:14:00 GMT

Almost to the day, Azure had another certificate related outage. Last year was more interesting I think and this year it was something different. My initial guess (remember I don't work for Azure nor do I have any knowledge about the details other than what has been communicated to the public) was that a few years ago when they were first creating Azure they generated some certificates to be used with SSL. My guess was that the certificates generated were valid for a long time. Probably like 5 years or something. Since the certificates were created long before azure was available to customers nobody thought about adding monitoring to detect when the certificates expired. Turns out I was wrong and that there were good alerting in place, but that the process had other flaws.

So how can you prevent this from happening in your Project? I would suggest you do the following:

During development use certificates with very short lifetime. Just one or two months. This way you get used to your certificates expiring and the monitoring you add to warn you when a certificate is about to expire will be tested on a regular basis.
When you do a risk analysis of your system remember to be detailed and consider the implications of your certificates expiring.
Learn from others! When things like this happens to the big companies, think about if it could happen to you.

The funniest thing about this outage is an article in Australia thinking this was caused by hackers... I guess I shouldn't get surprised that news papers don't check their facts...