GOTO 2012 - The Plus Side

I'm going to be GOTO again this year, and - as always - I'm excited about the program. Lots of exiting stuff going. While I will try not plan too much ahead, because I find it both more fun, and in the end also more educating to just go with the flow and see the talks that catch my attention when I'm right there at the conference, I have few things on my radar, that I'm most probably going to see:

• Monday morning I'll likely kick off the conference with Brian Slettens Webs of Data talk. I saw Brian last year give a good technical talk on testing REST APIs, and the abstract for this one sounds intriguing.
• Later monday I want to see Jonas Bonér talk about Akka - because Akka and Scala are so very, very cool!
• Tuesday I want hear Sam Newman talk about how to design for rapid releases, because that's something I've been spending time thinking about too. It's a fascinating question really: How does the design of the software - of the code - effect the speed at which we can deliver. This is not just about how cruft slows us down, but also how to make software that we can build trust in quickly, which lends itself to automation and so on. I'm curious what Sam has to say.
• Tuesday I also want to hear a little something about R. Mainly because I know nothing about R except that there seems to be a growing hype around it. And also languages are fun, so of course I need a language talk!
• At the face of it Wednesday seems a bit slower for me, but I'll probably go see Dan Norths talk and Liz Keoghs talk, because both are such passionate, opinionated (in a good sense) and well spoken people.

You can see my (very) tentative schedule on this need thing GOTO made.

If you're going, create your schedule on the GOTO site, and post the link in the comments. I'd like see what caught your eye.

Draupner: Full Stack ASP.NET MVC Scaffolding

A little while back I announced on twitter that Mjølner had open sourced it's ASP.NET MVC scaffolding tool, Draupner:

Mjølner just OSS'ed our #aspnetmvc scaffolding tool, Draupner. Uses #nh, #fluentnh, #castlewindsor, #automapper, #elmah bit.ly/MKckRP
— Christian Horsdal (@chr_horsdal) August 11, 2012

Since then Draupner has been updated to produce ASP.NET MVC 4 apps, and all the dependencies have been updated too. So now since like a good time an introductory post about Draupner.


Why Did we Build Draupner?
Scaffolding is not a new concept. It's been used for while in other web frameworks, and moreover Steven Sandersons ASP.NET MVC scaffolding has been around for a while too. That begs the question why another scaffolder? Basically because the existing ASP.NET MVC one does not do what we (Mjølner) want the way we want it: We want a simple command line tool that can

• Set up a new ASP.NET MVC solution with a "Web" project along with an associated "Core" project and a "Test" project.
• Add further entities to the solution as needed throughout the solutions lifetime
• Add CRUD operations and GUIs to existing entities
• Add tests for all the other stuff it adds
• Allow us to code away happily on the solution without having to think about making the scaffolding tool happy

Furthermore, and importantly, we wanted everything the tool produced to follow an architecture we've used successfully time and again. This means setting up a certain structure in terms of projects and folders, as well as building on a certain technology stack that we like to work with. In other words the tool, Draupner, is a set of practices we at Mjølner have had succes with put into code. These last bits are what sets Draupner apart.

What Technology Stack does Draupner Set Up?
Draupner projects uses a bunch of technologies, that we've found to work well together. All of them are set up as NuGet dependencies (except Rake). The stack includes:

• ASP.NET MVC 4
• NHibernate
• Fluent.NHibernate
• Castle.Windsor
• Elmah
• Log4NET
• Automapper
• Rake 

You can see the full list on the Draupner page on Github.

What Does a Draupner Solution Look Like?
Let's have a quick glance at a solution built with Draupner. This screenshot shows which projects such a solution consists of:

The .Web project is the ASP.NET MVC site: It includes views and some thin controllers, that rather quickly call into the .Core project.

The .Core project is where the domain model goes and where the persistence of said domain model is handled. We like intelligent domain models, so this is where the smarts of the application is meant to go.

The .Test project contains xUnit tests for both the .Web and the .Core projects.

This is all set up by Draupner during the initial project creation. Moving on from there Draupner can add further entities to the domain model and add CRUD operations/GUIs to those enitites. Taking a look inside the .Core project we see:

This gives a peek into the technolgoy stack used by Draupner projects: Entities are persisted to a SQL Server database via NHibernate (you can reconfigure NHibernate all you want if you e.g. want to change to MySql), and the NHibernate mappings are set up with Fluent.NHibernate. Draupner also create repositories for the enities it creates which the the controllers in the .Web project can use.

Also notice the Castle.Windsor dependency: All the code produced by Draupner uses dependency injection and inversion of control.Caslte.Windows is the IoC/DI container of choice used by Draupner proejcts. E.g. the repositories mentioned above expect an IUnitOfWork into which it can enroll operations. This is injected into them by Windsor. Skipping ahead a bit let me mention that the .Web project sets up an NHibernate unit of work per web request and registers it with Windsor.

Lastly we can notice that Draupner sets up Log4Net, so that it's ready to go.

Let's move up the stack and open up the .Web project:

We can see that Draupner has created controllers for the enities it created. These each allow for simple CRUD operations.

Draupner has also created simple, but nice Ajaxy CRUD views for the entities. Neither of these are really expected to be used in production, but act as placeholders until "the real thing" is implemented.

Draupner has also created a few view models, which are used in the CRUD GUIs and has set up Automapper configurations to map between the view models and the enitites in .Core.

Worth mentioning is also that the .Web project uses Elmah for error logging in the web layer.

As mentioned Draupner creates tests for all this as well. They end up the .Test project:

The tests are xUnit tests and use AutoFixture and Rhino.Mocks.

So What Now?
If this caught you're interest go clone the Draunper sample project on Github and take a harder look at how things are set up or take Draupner for a spin, following the instructions in the readme. If you like it, but find something missing or not working let us know. We're not making any promises with regards to support and bug fixes though, so an even better idea is to send a pull request. Those we do welcome.

WPF View Smoke Testing

I enjoy TDD. I enjoy the way it makes me code and I enjoy the rhythm. That is, I really enjoy TDD'ing the logic in my applications: The business logic, the controller logic, the domain logic; wherever there is logic that I can isolate and unit test cleanly TDD is just all fun and productivity. I enjoy TDD'ind integration points a little less: The database access, the web service calls, and so on are slow to test, so the TDD rhythm is broken. I still prefer TDD'ing these parts too though. I do not enjoy TDD'ing UIs: In my experience the tests are slow, either the rate of false negatives is high or the rate of false positives is high, and UI test are a pain to write (don't even get me started on the horrors of recording UI tests). Therefore I usually settle for subcut tests and manual UI testing when it comes to views. That is: I want to TDD my presentation logic, but am usually ok with checking that the pixels are in the right spot manually.
Working with WPF this is - at first sight - supported by MVVM: The view models sit right under the views, and are able to cut the .xaml.cs code behinds down to (almost) nothing, so testing the view models is subcut testing right? Right?? Not quite: There is a little bit of stuff going on in the bindings. I want to test that stuff.

WPF has been around for a while so I expected this to be a solved problem. Maybe it is, but my googling didn't yield an answer. It did however yield a number of candidated solutions. Below is a quick summary of my evaluation I of these candidates. (TLDR: None of the libraries worked, but Window.Show and FrameworkElement.FindName turned out to be my friend, and maybe, just maybe. Approval Tests could finally win me over to UI testing).

Notes From My Evaluation

Below there is a section for each of the candidates I quickly evaluated with some rough notes on how it went. The evaluations are not terrible thorough nor objective, so YMMV 

IcuTest

IcuTest is a library that works by asking you the first time a test is run to accept or reject the result: It shows you a snapshot of the window to assert on, and you accept or reject. If you accept the image is saved and used as the acceptance criteria in subsequent runs.
I have a few issues with this: The asserts come down to bitmap comparisons, which means (1) that they are imprecise - they assert on the whole window/control instead of just the one thing the current test is about and (2) they depend on the machine the test is running on. These are execatly the issues with UI testing that have bitten me in the past. So IcuTest is not what I'm after.

White

White seems to be the most grown up UI testing framework for Windows applications around. Promising. But: I installed the NuGet in my projects and was immediately sent into the Log4Net strong naming cirkus. Annoying but not Whites fault.I went on to clone the source off Github. It compiled out of the box, but most of the tests failed. After fiddling around for a few hours I got like 60% of the tests running. Not a good sign to be honest. The fiddling included changing things like which properties were used to input text into a textbox in ways that were pure guessing on my part. All in all this seemed like a route that would lead to unstable tests. So White is not what I'm after.

AvalonTestRunner

The AvalonTestRunner is an old thing from back when WPF was still Avalon. It doesn't claim to do a lot either. But none of these are bad things in themselves. If it works it works. One of the things AvalonTestRunner claims to do is sanity check all the bindings in a view: I.e. throw an exception if there is a binding path that is not found in the data context. That is part of what I'm after and actually a quite nice first line of defense to have. Only problem: I couldn't get it to work, not out of the box and not after debugging through the source for a while. Maybe it's just me, but again I concluded: AvalonTestRunner is not what I'm after.

Guia

Guia seems to try to solve the same thing as white but only for WPF. It also seems defunct: The current version is 0.1.1 and is 2 years ole (at the time of writing) . But again: If it works it works. Sadly it didn't work out of the box, and because of the lack of activity I didn't investigate further. Guia is not what I'm after.

Hand Coding

With all the libraries I tried out not really working I'm left with hand coding the tests myself. As it turns out this is in fact not nearly as bad as it sounds  - not for the subcut type of tests I'm after anyway.

MS UI Automation lib

MS UI Automation is a library intended to support building screen readers, remote controls and other types of applications that need to automate the UI of some other - known or unknown - application. It seems to provide everything you'd need to write UI test for WPF. I haven't tried it out though because it seems like overkill for what I'm looking for.

.FindName

As it turns out I probably shouldn't have spent so much time wading through testing libraries because the simple little kinds of tests I set out to write: Tests that drive and check the bindings in my XAML are actually (for the most part at least) easily written by just opening the window under test directly, finding the controls of interest by calling .FindName on the window under test and then manipulating or asserting against properties on those controls. Like this:

This is so darn easy, that once I realized, that this is actually what I am after I stopped looking at libraries although there are still a couple on my list. So there you have it: It's just not complicated enough to need a library.

Promising ones I haven't gotten around to evaluating

In spite of the conclusion above the following may be worth checking out. I'm pretty sure at least ApprovalTests work although I haven't tried it. WhiPFlash seems active, but beyond that I know nothing.

ApprovalTests

WhiPFlash