- There is a recorder so you can quickly create a test case by clicking thought the application
- There is an assertion builder where you can say “this element should be red”, “this checkbox needs to be checked”, “this image must be visible”
- There is special support for all kinds of widgets like text editors where “position” is row/column (i.e. cursor position) instead of mouse coordinates or character offsets. The test API allows for checks like “is styled like a keyword”.
- If the UI is resized after the tests have been recorded, the tool will try to calculate the relative click point. Unless the UI element is special (like a graph editor) where it has different heuristics (like when you clicked in an empty area but now, there is something below at the coordinate). If everything else fails, the testing tool will try to resize the UI element to the recorded size.
- There is a compact, extensible DSL to describe the test cases. The DSL supports procedures so you can reuse test code.
The tool was fast and stable during the demo. It could reset Eclipse’s workspace to a certain state (open perspective, open editors, open projects) – I’m currently thinking about using it to create the default workspace for our development team.
One more things from the demo: Black box testing is a myth or at least a dream. A testing tool for anything complex needs to know internal details (like Eclipse’s background jobs). Otherwise the tests will either fail randomly when some background job didn’t complete in time or they will be slow (since each of them will be sprinkled with “WAIT 1 MINUTE” instructions) or they will be sprinkled with application specific “wait” instructions.