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

Book review: Scala in Depth

I read Scala in Depth by Joshua D. Suereth over last week, which really is not giving it the time and attention it deserves. Furthermore I'm no Scala expert - although I'm not a complete novice either. Anyway here are my thoughts on the book.

Is it any good? Or TL;DR
Yes, it's good. It delivers on the promise of the title it is - as far as I can tell - really is Scala in depth. It does so with a mixture of some theoretical background for the different language constructs and a lot of practical Scala programming advice coming from the lessons the author has learned through his own use of the language. Where it sometimes lacks a bit is in introducing stuff before using it. This is not a problem if you have a basic working knowledge of Scala already, but I image it would be, if you didn't. Bottom line: I'd recommend Scala in Depth to anyone who - like me - has dipped their toes in Scala and want to learn more.

The language
The book starts off with a very quick introduction to the very basics of Scala - it's a statically blended OO/functional language with a very flexible syntax and grammar running on the JVM (and to some extent .NET if you really want). This introduction includes the REPL and a few tips like "prefer immutability". This should be enough to give you a feel for the language, and to get you startet playing in the REPL.
Once the basics are out of the way the book becomes somewhay more hard core - not in an academic language semantics kind of way, but in a practical way, where the reader through the book is taken through a number of sometimes hairy examples. These gives a thourough run through of the object oriented parts of the language (like classes, objects, traits and polymorphism), the type system (like generics, higher kinded types and existential types) and the functional parts (like functions, higher order functions, and some basic functional patterns).
All in all these parts of the book in themselves provide an in depth look at Scala. But not a very practical one: Knowing of the language features and even knowing the ins and outs of them is not the same as being able to use them well. These practicalities are addresed by the more style oriented parts of the book.

Style
The other part of the book - which is not pulled out as a separate part, but interleaved with the rest of the book - is the advice on style. To me these are the most interesting parts of the book. This where the book gets into things like demonstrating how to use actors effectively and safely, how to use implicits sanely, a map of the collections library and integrating with Java. These are things I suspect you'll need in real life development, and which are painful to go through learning by yourself.

All in all a very informative book that can take you from a basic knowledge of Scala to a thorough knowledge of the language - given that you take the time to do some serious coding along side your reading. If you just speed through the book - like I did - you'll learn less, but still a significant amount.

Slides from my Community Day Copenhagen 2012 Talk

I did a talk on "alternative" .NET web frameworks, because I think it's important to realize that there are serious alternatives to ASP.NET - even in .NET-land. Anyway here are the slides:

Four .NET Web Frameworks in Less Than an Hour

View more presentations from Christian Horsdal.