Testing user interfaces is usually a pain in the butt. No matter how cool your UI is, it will often boil down to a brain-cell killing process clicking the same buttons over and over again. Thanks to the Geek Gods of .Net though, there are ways to automate this, and it’s not even that tough to do.
In this post, we’re going to use Automation peers to expose a button to a unit test, and have the test start the application, click the button, and confirm that the button does what it’s meant to do. We’re going to use MbUnit to write the test, and NBehave to make the tests nice and clear.
Last week, Marlon blogged about how to avoid adding command binding code to code-behind files. The idea is both simple and great, and allows you to keep your code behind nice and clean, and your layers separated. There’s only one (and yes, I’m being very anal here) thing that bugged me with it:
DataContext = new ViewModel(new SampleModel());
or, for that matter, “DataContext = anything”, is still in the code behind class. This can easily be sorted out with some easy data binding and a supporting class. Continue reading
I meant to write something about MEF after my holiday, but I’ve been sidetracked
for a while. One of the things that happened to divert my notoriously unstable attention was a quite excellent five day Blend course by Brennon Williams. My preferred method of writing XAML has been, so far, in a text editor, but Herr Williams was quite persuasive in demonstrating that Blend is, in fact, far, far better for the job.
As part of the course, we wrote a small application. I ended up hacking together a 3d carousel user control for this, which I felt was pretty cool, so I set about rewriting it as a custom control for future use. No, I did
not use Blend. Yes, I did notice it’s a damn sight harder to do it in pure code than it was in Blend.
Warning: This post contains some math. Continue reading
A must-have if you plan to use Blend for any length of time: