One of the things I have still not talked about in any of my talks is about testing GUIs. The reason is pretty simple: I don't really do that. I find that the amount of effort it takes to test a gui with NunitASP (whichh just resleased a new vertion, BTW) or NunitForms is much higher that it is to simply separate as much logic as possible from the UI layer and test that functionality.

I do believe in a test-first fasion - but I'm also a realist. Its jsut too time consuming and the benefits I'd get from it are minimal. If I don't test the GUI, however, the ramifications are not that horrible and usually very easy to fix.

 

One thing that I do want to get into is the whole issue of customer tests - using the FIT framework. It's a pretty awesome idea actually: You wrap your object model in a testable and simple object model wrapper which internally calls your real objects and contains various properties that return results.

You then let the customer write their own tests against your custom objects, only they don't program against them

they actually fill out HTML tables in which they specify the object they want to instantiate, the method they would like to trigger, and the expected results of that call. It very user friends (compared to coding, anyway..) and I can see this as something that could change the way we face the customer today before a major release.

I still have a few problems with it though. Such as - when do you actually take the time to write that object model? Customer tests are supposed to be written as the application is written. they also arenot a replacement for unit tests, so when do we have time to write them? do I code up a new method to my object model each time I write a new unit test? where exactly in the coding chain do customer tests fit in? how much extra work are they? Is the amount of extra work justifiable?

I'd love it if someone with real world experience in that are has some comments on this matter.