Using NDepend to identify areas of interest in a code base.
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.
Some years ago, a short while before I started stress testing my first set of diapers, Lennon was singing “Life is just what happens to you when you’re busy making other plans“. That was just the the first phrase that went through my head when I was told, last week, that another product would be pushed through the Certified For Windows Vista process. The phrase that followed was (reproduced here in a highly sanitized form) “Oh dear, we’ll have to run Test Case 22 on every installer”.
For those lucky people who have not yet had the dubious pleasure of running this test, it goes something like this: you open two instances of Orca, once containing your installer and one containing the reference schema. Then, you go through 80-odd tables, making sure that no custom fields have been added to the standard tables, and no custom tables (and their fields) have names starting with the “MSI” prefix. It is, in short, a drag, and a necessary one at that. You can read more about it in the Certified For Windows Vista Test Cases document.
Having a low boredom threshold, I know that if we were to do such a test manually, chances are that I’d miss something, with all the ensuing hilarity. This sounded like a job for [dramatic pause] a hastily clobbered together script! [fanfare] Continue reading