@Pavel:

Generally, automated testing at the UI layer is hard/brittle/complex even with appropriate tools and this is generally why you want to look to design your winforms -or- web apps such that its possible to test nearly all your logic independent of exercising the UI itself.

With the web, since the results are just HTML in your browser its easier for 3rd-party/OSS tools to automate reading results and sending HTTP requests to your actual applicaiton and so things like WatiR, WatiN, Selenium, etc. have grown up to address that need. Winforms, however, is a very different beast since its UI ‘output’ is much harder to ‘intercept’ in order to see responses and automate control clicks, etc. There are a number of commercial packages out there that address this need (sounds like you are already aware of some yourself) and even the seemingly-defunct NUnitForms project in the OSS space, but -generally- these are awkward and brittle automation tools that provide a dubious ROI (IMHO) unless your UI is really stable (not many design changes between iterations).

Overall, except for some corner case projects where it makes sense, I recommend people try to stay away from UI automation testing as its is rarely worth the hassle (sorry, UI test automation vendors, that’s just my opinion based on my experience).

As an aside, I heard a very interesting thing about UI automation testing under WPF: the accessibility API (designed to allow visually-impaired users to interact successfully with WPF apps) seems to expose a large API surface that I have heard makes automated UI testing of WPF apps a more reasonable goal than is the case for ‘traditional’ winforms apps, but this is just something I read/overheard somewhere rather than my personaly experience so YMMV.

Good luck and hope this helps~!

@bydlo:

That’s really a great question (and I thank you for pointing out that my prior-stated stance on NO BETA FOR PRODUCTION WORK seems in conflict with my choice of ASP.NET MVC for this series/project). I appreciate your keeping my honest 🙂

My reason for choosing ASP.NET MVC (even tho its still in BETA) is the same as my choices for other technologies: I am splitting the difference between ‘technology has to provide significant value’ and ‘technology has to be of interest to as many people as possible’. This is largely the reason for my choice of ASP.NET MVC over MonoRail (with which I also have experience I could share).

Sadly, although monorail had ‘first-mover advantage’ (or if not first, certainly gained the most traction IMHO among .NET developers interested in an alternate to ASP.NET Webforms), it never really saw terribly broad adoption. With ASP.NET MVC’s impending release, there is a chance that some of the mindshare that its getting will spill over into MonoRail when *some* will discover many things that MonoRail does better than ASP.NET MVC, but my sad expectation is that this will not manifest itself in a big way.

I don’t expect that the interest in ASP.NET MVC is going to significantly increase the adopters of MonoRail in the same way that something like Unity has increased the number of Castle Windsor, StructureMap, NInject, etc. adopters or that Entity Framework has increased awareness of NHibernate.

I actually think this is for several reasons:

1) EF and Unity aren’t really entire ‘platforms’ (despite MS PR to the contrary!) in the same way as ASP.NET MVC is

2) its very likely that a third-party product ecosystem (control vendors, etc.) will grow up around ASP.NET MVC in the same way its done around WebForms and this is not expected to happen to MonoRail anytime soon IMHO; this will further stiffle an increase in MonoRail from ‘dissatisfied ASP.NET MVC adopters’

3) The very real limitations of Entity Framework and Unity are things that any real-world dev would bump into almost immediately upon their first real-world/non-demo use of these technologies and so anyone serious about ORM or IoC quickly looks for another solution and usually finds it in OSS. The limitations of ASP.NET MVC are a bit less i-your-face and tend to be exposed only by less-common edge-cases and so adopters of ASP.NET MVC aren’t as likely to get dissatisfied so quickly and look for alternatives (MonoRail) in the same way

Sorry this is a bit long-winded, but if you regularly visit this blog or watch my screencasts, I’m sure you’ve come to expect nothing less from me 🙂 but the answer to your last question of “do I think its stable enough to base a real application upon?”, the answer is YES. On my own team at my company we have two such projects underway right now that we are basing upon the ASP.NET MVC BETA platform but are expecting to complete 1Q2009 at which time we expect the final RTM bits to be completed.

The success of StackOverflow as a viable site on this technology (technically still based upon the preview bits and not even the BETA release AFAIK) has given us the confidence to proceed this way and I’m letting that confidence spill over into the SkillPortal project for this Autumn of Agile series too.