Women in Technology

Article:		Top 12 Reasons to Write Unit Tests
Subject:		GUI testing
Date:		2003-04-04 04:29:10
From:		anonymous2
Generally I'm a massive fan of unit testing, but in GUI programming this approach tends to break down. Particularly in a SWING rather than a web application. Simple tests like "I click on the button and the main application launches" are incredibly difficult to test for with a test suite and much more straightforward with a test script. The problems are manifold; test scripts are open to interpretation, and not always followed exactly. It's easier to write a test script than a unit test, so there is the temptation to do this where a unit test would be practical. Does anyone have any suggestions for tackling this problem ?

Showing messages 1 through 2 of 2.

• GUI testing
  2003-04-15 05:44:40  anonymous2 [View]
  
  
  Have a look at http://Abbot.sf.net or similar tools.
  
  xix [nine-teen]
  

• GUI testing
  2003-04-07 06:42:05  anonymous2 [View]
  
  
  We've experienced the same problem in our .NET Winforms apps. Initially we overcame it by coding a 'robot' class that would open a form, find the appropriate controls and then operate on them. We would interrogate the form/database to verify the outcome was what we expected.
  
  Argh. It works, after a fashion, but we couldn't devote the time necessary to make a really good robot tester, so it's not multithreaded and that creates some problems...
  
  I've read recently about someone who put all GUI-based methods into a separate class. When he wires up the GUI, he just calls a method in another class that does stuff. I think this is one way to go, though I'm not sure about how you'll manage verifying GUI actions based on successful method calls. I suppose that as long as your GUI reacts to values returned from the class, you'll be fine.
  
  We've resolved that on our next project, we will avoid GUI testing (by actually loading a form, that is) like the plague, by any means necessary.