Tutorial: JUseCase + TextTest

This tutorial describes how to use TextTest to create and run GUI tests based on JUseCase. It will only describe the steps specific to GUI/JUseCase based testing, for general information on how to use TextTest you are referred to the TextTest homepage.

What is TextTest?

TextTest is a tool for creating, running and maintaing acceptance tests. It is open source and free to use. The TextTest homepage says: "As the name suggests, TextTest works via comparing plain text logged by programs with a previous 'gold standard' version of that text. This is in contrast to most acceptance testing frameworks on offer today, which generally use some form of hand-written 'assertions' by the test writer that call into an application API."

One reason why TextTest is mentioned here is that this tool has built-in support for JUseCase. Using TextTest you can record (create) usecase scripts for your application, as well as running tests based on those usecases. There are a few things you have to do to configure TextTest for use with JUseCase, but when you're done TextTest will automatically create the jusecase.properties file for you when creating/running your tests.

Configuring TextTest for use with JUseCase

We will not go through how to install TextTest, nor the basic setup work needed to get an application running via TextTest. For such instructions, go to the TextTest homepage. Instead we will only go through those extra TextTest configuration file entries required to run GUI tests. Those entries are:

Assuming you already have a TextTest configuration file for your application, this is what you would add to it to enable JUseCase support:

use_case_record_mode:GUI use_case_recorder:jusecase slow_motion_replay_speed:2

Recording a test usecase

Once you have created the TextTest configuration file for your application you can start populating the test suite. Adding a test directory (or simply a test) to the suite for a GUI application is no different compared to non-GUI or batch applications - the difference lies in how the test is defined. For non-GUI applications you typically set some command line options, but for the GUI application you simply click the "Record Usecase" button. TextTest will then create a temporary directory from where it will launch your application. TextTest will also create the necessary jusecase.properties file for you, and point the "record" entry to a temporary usecase file in the directory. Once done (when you have quit your application) TextTest will collect the recorded usecase file and put it in the TextTest test directory.

The description above assumes your application doesn't require any data files or command line options. If something like that is needed you have to specify that (via the configuration file and/or the options file) before you start recording the usecase. This is nothing specific for GUI applications and usecase recording, and the TextTest homepage will tell you exactly how to do it.

Running the test

Running a JUseCase based test is no different compared to how you run tests for other types of applications. TextTest will again automatically create the jusecase.properties file for you and point the replay entry to the usecase in your test directory. It will also add a record entry pointing to a new temporary usecase file. When the test has finished, TextTest will, in addition to comparing any output or data files specified in the test, also compare the usecase files to make sure that what was replayed also was re-recorded. This in itself is some kind of description of how your application behaved, but you probably want to have a more detailed behavior log, and the log4j package is the recommended way to do it. Log4j is well known and tested, and also used by JUseCase internally, which means you can enable JUseCase diagnostics through the same log4j configuration file you use for your application (more on that in a later tutorial).

When replaying the test, if you want to follow what's happening, just tick the "Run with slow motion replay" checkbox in the TextTest GUI and TextTest will then add the delay entry to the jusecase.properties file it creates. It will be set to whatever you set "slow_motion_replay_speed" to in the TextTest configuration file.

JUseCase diagnostics via TextTest

TextTest has built-in support for running a test with different diagnostics settings. This works by having a default diagnostics setting, with an option to override them with test specific settings. In order to get this functionality working, add the following diagnostics section to the TextTest configuration file:

[diagnostics] properties_file:diagnostics input_directory_variable:testdiag_readdir write_directory_variable:testdiag_writedir configuration_file:log4j.properties [end]

Then create a log4j.properties file containing the default settings and put it in the same directory as the configuration file. If you choose to redirect some logging messages to a file, using a log4j file appender, and you want TextTest to find that file, be sure to include ${testdiag_writedir} in the path, like this:

# redirect output to the file "dummy.txt" log4j.appender.dummy.File=${testdiag_writedir}/dummy.txt