AutoTest.Net updated - now (and then) notices broken builds

2010-11-14 Development .NET / AutoTest.Net / Testing

I received a useful comment on Friday's post about AutoTest.Net. In the wee hours of Saturday, Greg Young, wrote to say

It should detect broken builds without any problem. We have been running it daily for about 1.5 months.
Perhaps you could grab me via email and reproduce it?

Well, I wasn't going to pass up that offer. Off to GMail!

7:15	I grabbed him
7:20	he was making specific requests for additional information, the output of test runs through the console runner, and the like.
8:00	he had dived into the code to verify that things were working as they should, and asked for a sample project that exhibited the bug.
8:20	I sent the code
8:31	I e-mailed that I'd accidentally sent a project that complied
8:34	Greg reproduced the problem
8:54	he sent me a replacement .zip file
9:04	it worked!

As soon as I broke the compilation, the monitor lit up, showing me which project failed and where:

[Info] 'AutoTest.Console.ConsoleApplication' Preparing build(s) and test run(s)
[Info] 'AutoTest.Console.ConsoleApplication' Error: D:\bconrad\Documents\Source\BlogExamples\2010-11-autotest\BookFinder\BookFinder.Core\BookListViewModel.cs(50,17) CS1002: ; expected [D:\bconrad\Documents\Source\BlogExamples\2010-11-autotest\BookFinder\BookFinder.Core\BookFinder.Core.csproj]
[Info] 'AutoTest.Console.ConsoleApplication' Ran 1 build(s) (0 succeeded, 1 failed) and 0 test(s) (0 passed, 0 failed, 0 ignored)

It turns out that the bug had already been fixed on trunk version of the code, but for some reason hadn't been built into the Windows installer. Turnaround time: 1 hour 49 minutes from my initial e-mail, and that included:

me drifting off to other tasks between e-mails, increasing delays
a session of trying to work around GMail hating the zip file I tried to send
a delay imposed by my having sent a bad test project

I'm sure those things added a good half hour to the required time.

Then he spent another 40 minutes on a non-existent problem that I reported. I'd left an older AutoTest.Net WinForms monitor running during the debugging, so when things finally settled down, I got a pair of toasts from Growl - one reporting build failures, and one reporting successful builds when there weren't any. When I discovered that, Greg was already installing a new Growl for Windows to try it out. And he was very gracious about my error and his wasted time.

I'm hardly the first to point it out, but this is one of the great things about open software. It's great getting that kind of service so quickly. And on a weekend no less.

Will this encourage me to use AutoTest.Net

Sure. My primary complaint with it has been resolved. Moreover, I'd be even more inclined to see what comes of Mighty Moose, now that I see the dedication of the developers behind it.