In 2007 I've worked a lot with NUnitForms. It contains all major controls testers and you can easily create

your own ones for e.g. a Data Grid or a 3rd party control. I had to create one for Janus GridEx and it wasn't really

that hard. A little reflection went a long way :) Lately, the whole project was at a standstill for some time but now it seems

it's revitalizing nicely with new people on board. So if you haven't yet go take look. This is just one open source GUI testing platform

and I'm sure there are others... I haven't checked them out though.

Now to the big question: Is it worth it?  It depends...

I'm not a hardcore TDD practitioner but I like having repeatable unit tests. But having automated GUI unit tests is in my opinion a waste of time.

Why? It simply isn't worth spending time writing them. You should have enough code coverage with non GUI tests to find any bugs long before

hitting the GUI. You might want to be tempted to unit test control positions or visibility or some other property... don't bother.

You'll spend your time better if you write more non GUI unit tests and check your GUI by hand (eye).

So what are they useful for? Well... I've used them for acceptance and integration testing with great success.

Integration Tests...

... test how different parts of your application work together. These kinds of GUI tests proved to be VERY useful and they are worth investing time in.

They have a great ROI (return on investment) once they're written.

For example we had a large workflow based application that was completely async in nature. It had a windows forms client that could be deployed on

multiple computers, all those clients connected to a single server that hosted a few webservices for data modifications, retrieval and some other stuff.

The whole app was also connected to Sharepoint server,  Exchange Server, SQL Server, used InfoPath and a 3rd party software to export data from

and into it. With one single GUI integration test we could easily see if everything worked together as it should. We mocked the InfoPath and

3rd party software but everything else ran great.

The point of using GUI tests here is to see how and if your whole application works with all parts integrated together from GUI interaction

to Exchange connectivity. Even the best non GUI integration tests simply don't do that.

Acceptance Tests...

... test if your software is up to some specs usually defined by the business process. They're in essence a black box test.

You don't care what goes on inside the software you just want to see if the output is correct for a certain input.

In workflow based processes this can be very useful since you know what the input and output parameters are for your workflow.

For example you start the workflow in your app via NUnitForms, pressing "move in workflow" buttons until the workflow end and then check if

the output parameters have the correct values. You can check for various different GUI parameters in this test along the way but as I said above

don't go overboard. I usually just check for visibility of certain panels or grids... simple things like that.

When I first started with GUI testing I thought it was a really big waste of time. And to tell you the truth if you don't draw the line somewhere it is.

I even had a moment when I thought it was a good idea to test everything only with GUI tests. That was so far over line I couldn't even see it anymore.

Luckily that moment passed pretty fast. Don't make the same mistake. If used wisely automated GUI tests are a big benefit.