Rickard Nilsson

I’ve been working extensively with ServiceStack lately and I really like what they’ve done. As it contains the full stack for building HTTP based services from text serializers to development tools to a micro ORM it’s very easy to fall into the pit of success. I don’t mind picking and choosing these things for my self, however it’s nice that is doesn’t require any brain power making choices. Plus you can always be assured that the tools you get in the box is quick to get started with, and has all the performance you’ll ever need. They might be too simplistic four your needs but then it’s nice to know that its usually very simple to replace them with something else.

Let me tell you a story.

I was cruising along doing my thing, test-driving my code and was feeling pretty good about myself. I was hitting a very high code coverage as I was only writing a little bit of test code, a little bit of production code, and refactored as I went along. Now, I hit a pain point which showed itself to be very difficult to get under test. It was the few lines where I actually called the database through OrmLite’s extension methods.

OrmLite is a micro ORM and is part of the basic ServiceStack package. It is a set of extension methods on top of System.Data.IDbConnection which makes it very easy to use at the same time giving you direct access to the underlying APIs. It consists of operations like Insert, Update, Select etc. and is really easy to get started with.

Anyway, as OrmLite is only extension methods on IDbConnection I though it’d be simple as cake to fake it out such that I could get my database calls under test as well.

Turns out it was way more difficult than I had anticipated. After a little while I gave up and left a total of four lines uncovered (one line per entity).

The other day I was looking through the ServiceStack documentation after something totally unrelated and stopped at a couple of lines that caught my attention.

// Use in-memory Sqlite DB instead

var dbFactory = new OrmLiteConnectionFactory(

    ":memory:", false, SqliteOrmLiteDialectProvider.Instance);

So, it was possible to use an in memory database instance instead of the SQL Server provider I was using in production. Very interesting. Could I utilize this in my unit tests to get that last mile?

Lets see. I quickly wrote a little unit test to try it out.

   1: [TestClass]

   2: public class EntityRepositoryTests

   3: {

   4:     Entity expectedEntity;

   5:  

   6:     [TestMethod]

   7:     public void GetAll_All_ReturnsAllFromDatabase()

   8:     {

   9:         var dbFactory = new OrmLiteConnectionFactory(

  10:             connectionString: ":memory:",

  11:             autoDisposeConnection: false,

  12:             dialectProvider: SqliteOrmLiteDialectProvider.Instance);

  13:  

  14:         using (var db = dbFactory.OpenDbConnection())

  15:         {

  16:             db.CreateTable();

  17:             expectedEntity = new Entity

  18:             {

  19:                 Id = 1,

  20:                 Name = "foo"

  21:             };

  22:             db.Insert(expectedEntity);

  23:         }

  24:  

  25:         var repository = new EntityRepository(dbFactory);

  26:  

  27:         var result = repository.GetAll().ToList();

  28:             

  29:         Assert.That(result, Is.EqualTo(new [] { expectedEntity }));

  30:     }

  31: }

Sqlite is not included in the standard ServiceStack package, however it’s simply a matter of running a command in the Nuget Package Manager Console:

   1: PM> Install-Package ServiceStack.OrmLite.Sqlite32

for the test project and SqliteOrmLiteDialectProvider lights up.

When this was done NCrunch automagically picked it up and everything turned green immediately. Nice!

Running the test with MSTest was a little trickier as it turned out. Sqlite drops an interop dll in the test project as a resource which MSTest couldn’t pick up. To get that to work I needed to add the dll as a deployment file in the local test settings. When I did that, the whole thing even ran in the continuous integration build in TeamCity.

Awesome day at work. Hope you’ve found this tip useful. Cheers!

The foundation for all solid professional software development in my opinion is good craftsmanship practices and the most important of them is unit testing. It used to be great debate and controversy about weather unit testing was worth it or not but the fact is, the jury is back and the verdict is final. Unit testing is a core software development practice which can be ignored no longer, for any reason.

Unit testing is a relatively old practice and what has become the definition of a good unit test through decades of practice is the following:

• It’s automated
• It’s repeatable
• It’s easy to implement
• Once its written it sticks around
• Anyone can run it. Easily
• It runs fast

Given this definition there are many ways to produce these unit tests that are so important, but what has proven to be the most efficient way to get them done is to iteratively write a test before you write the production code which should make the test pass. Thus, using test-driven development, not only do you get unit tests written such that you can prove that the application is working as expected, but with test-driven development you get so many other benefits. It’s really about thinking through what your application should do and designing it to be testable which inherently forces you to make it more decoupled and cohesive, two of the oldest software metrics of good design.

With a suite of unit tests in which you trust, you are much more comfortable doing can do ruthless refactoring. Without tests you can’t. Refactoring is one of the core practices of test-driven development, and it’s all about making changes to the code to keep it flexible in order to make it easier to change and maintain.

When we’re doing test-driven development properly we’re working in very short cycles of writing a little bit of test code, a little bit of production code, and then cleaning up after our selves as we go along. When you do this you want to make sure that all your old tests passes for every change you make as well as only the test case you’re working on is failing as expected. This leads to lots of overhead of clicking buttons in the IDE or pressing short cut keys over and over again. What you really want is a way to run all the tests automatically when ever anything changes. This is where continuous testing comes into play.

Continuous testing as a practice is actually what you do when you’re doing test-driven development properly, however the term has been claimed by a range of tools which was sprung out of the Ruby community. It provides tool support for automatically detecting when you save a code file and then running the entire unit test suite and report the result back to you. Consequently it somewhat changes the way you do test-driven development because you never need to think about running your tests again. You simply keep on coding, adding another test, implementing it and meanwhile the red light has lit up and switched to green again as you’ve made it pass.

It might seem like a subtle change but I’ve found that it really changes and improves the flow when I code, plus using a tool like NCrunch, as a side effect, I get so many other cool features like code coverage and pass or fail status next to every line of code (see the image at the top of the post). NCrunch takes advantage of all the cores in my machine and uses parallel execution to run the entire suite of tests every time. It optimizes the build such that only the modules that are impacted by the change are built and run first so I get immediate feedback plus the rest of the test suite is running behind the scenes for safety.

Continuous testing tools for .NET:

• NCruch
• Mighty Moose
• Giles

Disclaimer: This is my view on how software development should be practiced in a professional environment. It is my own opinion and do not represent my employer’s view in any way.

TDD Katas has become very popular in a small segment of the development community and we call our selves software craftsmen. We are passionate about software development as a craft and engage in different activities to better our selves and our peers.

My first kata cast, for instance, has been viewed close to 10k times on Vimeo since its publication. Much of the attention is of course due to Roy Osherove linking to my blog post from his TDD Kata 1 page. This time Roy initiated a sequel, meant to introduce interaction based testing using mocks and possibly stubs, and continue the teaching process of TDD and unit testing practices.

The Kata Cast

The following screen cast covers the entire kata in .NET, complete with Osherove’s three steps as well as manual UI testing at the end.

For best viewing experience I recommend watching it on Vimeo.com in HD

String Calculator TDD Kata 2 - Interactions from Rickard Nilsson on Vimeo.

The tools I use are Visual Studio, ReSharper, TestDriven.NET, Moq for mocking, and NUnit.

The code

The code and Visual Studio solution for the finished Kata can be downloaded from GitHub:

Download source

Discussion

As Osherove mentions in his instructions, this kata is not as simple as the first part, nor as simple as most katas out there. The reason is the element of interaction based unit testing involved, which is quite difficult to wrap you mind around, and it took quite a while to get the steps right. I thought I should share my path to the kata in its present form for others to learn from and comment on.

The Kata

Step 1. Everytime you call Add(string) it also outputs the number result of the calculation in a new line to the terminal or console. (remember to try and do this test first!)

As I did this test first I started out pretty much as how it ended up in the cast. However, after a while I tried to take a step back and see if there were any smells in the code I had not yet discovered.

I found that I didn’t really like the mixed responsibilities that the Calculator class got when I introduced writing to the console. This could be seen as a logging feature and thus a perfect candidate to become an aspect (in AOP). I started playing around with PostSharp and ended up with the following solution which is quite clean.

Which, at most, leaves the mark of a custom attribute in the Calculator class:

The problem with this solution is the way PostSharp works. It does all its magic as a post compilation step so everything is pretty much static. This is a problem in a testing scenario when we need to inject the mocked console in this case, hence the smelly ContainerFactory.Current stuff.

Another problem with this solution is that in part three, the console app, we need to disable or override what is outputed. This ends up becoming a static mess which did not feel right at all. If you have another view on this please leave a comment.

Step 2. Create a program (test first)that uses string calculator, which the user can invoke through the terminal/console by calling “scalc ‘1,2,3’” and will output the following line before exiting: “The result is 6”

For step 2 and 3 I thought a bit about refactoring to a UI design pattern like MVP, MVC or MVVM but finally decided to drop it, mainly because I didn’t know any framework like that for console applications. If the application grows I think this is the right way to go, but for the known requirements it’s an overkill, especially considering how small the solution is.

Step 3. Instead of exiting after the first result, the program will ask the user for“another input please” and print the result of the new user input out as well, until the user gives no input and just presses enter. in that case it will exit.

I played around a bit with SpecFlow, which has ha free form Given/When/Then specification syntax, on the later part of the kata. However, I felt that I lost velocity so I dropped it as well. Maybe, if I had some way of conducting complete acceptance testing through a real console, I would have pursued this further. It was simply too much to write, for example:

Scenario: Prompt user for another input
	Given a new string calculator
	And the user has entered: a valid input
	When the program has outputed The result is 1
	Then the user is prompted for another input 
Scenario: Quit on empty input
	Given a new string calculator
	And the user is prompted for another input
	When the user hits enter
	Then the program should exit

Figure 3. SpecFlow Feature specification for the console app

If you have any thoughts, comments, suggestions, or any other feedback please leave them below or ping me on twitter.

Are you new to the concept of code katas? Read my previous blog post and watch me perform the String Calculator Kata.

In my never ending goal of self improvement in the techniques and tools I use I’ve been practicing a version of the Prime Factors Kata for a while.

The Prime Factors Kata, initially sparked by the infamous Uncle Bob Martin, is about finding an arbitrary number’s prime factors. In the cast I show how my TDD practice has evolved into a flavor of BDD, mainly to reduce duplication in the unit tests. I also show off the awesome power of my current toolset which includes the Visual Studio 2010 and the latest versions of ReSharper, TestDriven.NET, NUnit and NBehave.

Though my performance is not yet perfected I want to put it out there because I feel there are no C# version that can really match the Ruby version in elegance and wit. This is my attempt to show what you can do with the C# language when you know the frameworks really well.

Please leave comments and/or suggestions below or record your own kata session in response.

Prime Factors Kata in C# from Rickard Nilsson on Vimeo.

If you are new to the Prime Factors Kata, code katas in general, or TDD for that matter, you may find the steps I take unnecessary or weird. You may want to watch the annotated version in which Uncle Bob explains why each step is taken and why they are taken in that order.

• Uncle Bob’s annotated version

Many have recorded there own versions of the Prime Factors Kata which all inspired me in the way I practice it. The cast that inspired me the most is

• Uncle Bob’s Ruby version

there are also a few other C# casts worth watching for comparison by:

• Uri Lavi
• Slatner

Moles is a new framework from Microsoft Research for isolating objects in unit tests. With the framework you create test stubs by using delegates and you can route any .NET method you want, including non-virtual and static methods in sealed classes. In addition, the framework is free, making it a major competitor to TypeMock Isolator that has been alone on this functionality for a long time.

Moles automatically generates stubs for all classes in one assembly. Here is an example of how easy it is to change the behavior of the static DateTime.Now property:

For SharePoint

Mole’s strength to fake and reroute static methods and the like makes it a very powerful tool for isolating and unit testing code developed for SharePoint. Microsoft Research has a whitepaper that describes how to get started:

Unit Testing SharePoint with Microsoft Foundation Pex and Moles

Introduction

Here is a video that introduces Moles:

After I posted my Code Kata Cast I received some feedback regarding the ReSharper templates I use to speed up my coding. I decided to share them with the public (like so many before me) in hope that others may benefit from them, as I do.

rickardn-resharper-templates.zip (1,44 kb)

After you’ve downloaded the zip-file and unpacked it, open Visual Studio and the ReSharper Templates Explorer: Menu –> ReSharper –> Live Templates…

Click on Import… as the screen shot below shows, and find the file “rickardn-resharper-live-templates.xml”

 Then click the “File Templates” tab and repeat the procedure for the “rickardn-resharper-file-templates.xml” file.

 Good luck with your katas!

Have you ever come across the concept of a Code Kata?

For me it really took off after reading blog posts (1, 2, 3) by Unce Bob Martin and Pragmatic Programmer Dave Thomas. The concept is really simple: how can we, as programmers, better our selves and improve our techniques and proficiency in using the tools and processes in our every day work?

The suggested solution is inspired by the martial arts kata. You learn how to implement a solution to a specific problem and you practice all the moves in the exact same order over and over again. The point is that you should know the moves so well that you forget about them and focus on improving your key strokes and the use of your tool set. The never ending goal is to perform the kata with the least amount of key strokes.

The promise is that practicing these kata's often and regularly makes you a better and more productive programmer in that you are trained to act instinctively in certain reoccurring situations.

Calculator kata cast

Anyway, I've been practicing a kata based on a problem initiated by Roy Osherove and I decied to record it to get some feedback and maybe spread some knowledge on how I practice Test-driven development using ReSharper.

Calculator Code Kata Cast 1 from Rickard Nilsson on Vimeo.

Roy Osherove is giving an hands-on TDD Masterclass in the UK, September 21-25. Roy is author of "The Art of Unit Testing" (http://www.artofunittesting.com/), a leading tdd & unit testing book; he maintains a blog at http://iserializable.com (which amoung other things has critiqued tests written by Microsoft for asp.net MVC - check out the testreviews category) and has recently been on the Scott Hanselman podcast (http://bit.ly/psgYO) where he educated Scott on best practices in Unit Testing techniques. For a further insight into Roy's style, be sure to also check out Roy's talk at the recent Norwegian Developer's Conference (http://bit.ly/NuJVa). 

Full Details here: http://bbits.co.uk/tddmasterclass

bbits are holding a raffle for a free ticket for the event. To be eligible to win the ticket (worth £2395!) you MUST paste this text, including all links, into your blog and email Ian@bbits.co.ukwith the url to the blog entry.  The draw will be made on September 1st and the winner informed by email and on bbits.co.uk/blog

I've been working to get my head around the Model-View-Presenter pattern and I've focused primarily on a Winforms scenario. As it turns out there are numerous sources out there on MVP, some of which are focused on Winforms, e.g. [2, 8] and some which are not focused on Winforms but highly valuable just the same, e.g. [1, 4].

Figure A. Screen mock up 

However, none of the referenced sources discusses the issue of communication between MVP triads. All of them thoroughly discusses the ins and outs when you have a single presenter talking to a single view and a single model, but nothing about communicating with other MVP sets. I've also found that other people are also struggling with this problem and how to best solve it but no really good solution has presented itself.

The problem

Well, we start with an example to formulate the problem. If we look at the example of the humble dialog [8] this only covers a single triad so we make it slightly more complicated. We have two views, a parent view and a dialog view, and each view has an associated presenter, i.e. parent presenter and dialog presenter. Now, the requirement is that when a user clicks a button on the main view the dialog should pop up modally giving the user the possibility to change a property value. The value change should then be reflected in the parent view. Sounds simple enough, right?

The problem is to implement this leveraging the MVP pattern to achieve a loosely coupled, highly cohesive, and test friendly solution. Some of the questions are; who has the responsibility to create the dialog view, who has the responsibility to show the view, what is the result from the dialog view and who should act on it.

MVP Solution

There are many different ways we can go about doing this but since I'm into Test-Driven Development I'm gonna do it test first. I also like to do UI up front so I create a Winforms project in Visual Studio and start dragging and dropping. The simplest possible screens are shown in figure A.

OK, now let's start with our first test. We want the dialog to appear when the "Edit user name" button is clicked and following MVP the view should simply pass on control to its presenter. The parent presenter should then have the dialog view popping up. This is the first test using Rhino Mocks [3]:

The parent presenter should simply pass the control to the presenter of the dialog. Thus, the parent presenter has a dependency on the presenter of the dialog and the dependency is injected through a property:

Now, these interfaces and classes doesn't exists so first we have to create them. But before we do I see some code that has no test, namely dialogPresenter.Load(), so let's write another test:

So, the presenter simply tells the view to show itself. Remember that we're talking to an interface and that the view in the test is not the real implementation. We're only driving out the behavior of the presenter at this point but we're doing it in such a way that the view implementation should be as thin a possible.

Code generation

I'm using ReSharper [7] to generate the interfaces and classes that I dreamed up in the tests.

More testing

When the initial tests are passing let's move on. The next thing that should happen is the user providing a new user name in the dialog and clicks on OK. So lets write a test for the OK event. I realize that some refactoring is also in place:

Passive view and Observer synchronization

The last requirement states that the user name change should be reflected in the parent view. There are a couple of ways to do this but in this example I'm gonna go with the Observer synchronization [6] strategy because it provides a nice separation of concerns and is easy enough to mock. Note, however, that it is the presenter which acts as the Observable, not the domain object itself (User in this case). This is because I do not want to polute the domain model with event code. The previous test verified that a callback method is called whenever the name in the dialog is changed. Now, the parent presenter only has to hook up an event handler to the dialog presenter's event. Our next test shoes what should happen in the parent presenter when the event is triggered:

So, the presenter explicitly tells the view what to do. The parent view is an example of a Passive view [5]. The presenter's code is included below for completeness:

And then the view implementation which is as minimalistic as possible:

Conclusion

The way the MVP parts are separated makes a UI with allmost 100% test coverage but above all the UI logic is in a separate class which is not tied to a frame, thus enabling us to discover duplicated code and oportunities to refactor and keep the UI maintainable. I think that this is a great way of driving out a design since I start out with the client hat on and not the other way around were I first list a bunch of methods and properties on a class. IMO this kind of interaction based testing really lends itself to driving out interaction design, and tools like ReSharper really makes the developer experience pleasant and productive.

References

[1] Jean-Paul Boodhoo. Design Patterns: Model View Presenter
[2] Dan Bunea. Model View Presenter - is testing the presenter enough
[3] Oren Eini. Rhino Mocks - dynamic mocking framework
[4] Michael Feathers. The Humble Dialog Box
[5] Martin Fowler. Passive View
[6] Martin Fowler. Observer Synchronization
[7] JetBrains. ReSharper
[8] Jeremy Miller. A Simple Example of the "Humble Dialog Box"

1. Abstract 
2. Refactoring
3. Test coverage 

Proceeding with a solution there is no way of changing the implementation of the GregorianCalendar class to get the correct behavior so we have to go about this another way. One is to subclass the GregorianCalendar and override the GetWeekOfYear method. Another is to implement the GetWeekOfYear in a class totally separate from the .NET framework. I think that the first one is the way to go since the error that we're trying to correct is in the framework itself.

So, first we alter the help method in the test case to use our sub classed IsoCalendar (which we haven't written yet).

So, we are not in a compile state yet so lets do the simplest thing to get this running. I decided to subclass the GregorianCalendar class since what is wrong is the GetWeekOfYTear method of that class. I basically override that method like below.

We run the test a get a red bar. Fine, but now lets go ahead and implement the algorithm. However, this has been done over and over with varying elegantness. My favorite is the work of programmer and mathematician Julian Bucknall. His original implementation can be found at his blog. So, instead of returning -1 I call the GetIsoWeek method from Bucknall's implementation and take the modulus of 100 (since the result from the algorithm is of the form YYYYWW). We run the test and we get a green bar!

Now when we get a green bar there's just one more thing to add. The ISO 8601 week should only be returned when the parameters rule and firstDayOfWeek is set properly according to the documentation. In all other cases the GregorianCalendar implementation works just fine. We fix this with a guard clause at the top and we're done.

Summary

During this series we covered test coverage for the faulty implementation of weeks according to ISO 8601. We used Test-Driven Development to provide a fix using Julian Bucknall's really smart implementation. Next we should take a look at refactoring to design patterns.