Comparing tools for acceptance testing of custom GUIs


TextTest/xUseCase

Exactor

Fit/FitLibrary

Fit(core)

Marathon

Test Language Type

Domain Language

Domain Language

Domain Language

Tool-defined (“ActionFixture”)

Programming Language(Python)

Test Persistence Format

plain text usecase script plain text logs

plain text script

script embedded in table

script embedded in table

Python script

Support for driving tests via the UI

Yes

Yes – though not in domain language

No

No

Yes

Can record tests using the UI

Yes

No

No

No

Yes

Assertion mechanism

plain text file comparison

hand-assertion calling test API

hand-assertion calling test API

hand-assertion calling test API

hand-assertion doing widget state checks

Code changes required to get started

calls to xUseCase logging of relevant behaviour

creation of a test API

creation of a test API

creation of a test API

None (though naming all GUI components generally necessary)

Support for refactoring of test scripts

Domain language composite files (cannot pass arguments)

Domain language composite files (can pass arguments)

None at customer level – though can always refine domain language

None

Programming language : can be refactored in any way

Languages/toolkits supported

Java (Swing only) Python (PyGTK only)

Java and .NET

Java

Java, .NET, Python, Perl, Smalltalk, C++

Java (Swing only)

Support for multithread synchronisation

Application Events

Hand-insertion of generic wait statements (not domain language)

No direct support

No direct support

Hand-insertion of wait statements for widget state changes

Integration with other tools

Parallel testing on grid (SGE or LSF) Bug-reporting (Bugzilla)

Continous integration (CruiseControl)

Wiki (using FitNesse)

Wiki (using FitNesse)

None