Home United States USA — software Introducing a Parameterized Test Suite for JUnit 4 Introducing a Parameterized Test...

Introducing a Parameterized Test Suite for JUnit 4 Introducing a Parameterized Test Suite for JUnit 4

215
0
SHARE

This look at automated GUI tests tackles parameterized tests suites in JUnit 4, courtesty of a simple extension that provides the Runner class for that purpose.
Parameterized tests became valuable for me when I started automating GUI tests for web applications with Selenium and WebDriver: Although GUI tests are no unit tests for sure the JUnit framework is very handy for test definition, execution and result aggregation. Integration with CI is also available off the shelf. Once I had reached a good coverage of use cases in a single browser, I wanted to port these test cases to other browsers as well. Thus, I parameterized my tests with the browser being the parameter and ran these tests on Chrome, Firefox and Internet Explorer. Since all my tests should be executed on all browsers, the next logical step was to define these parameters at the test suite once instead of defining them repeatedly for every test class.
Wanting to define parameters on suite level and having the use case of test automation in mind, I implemented and published an open source library as an extension of JUnit 4. Integration is easy and uses the same patterns as in parameterization of single test classes.
Start by defining another dependency in addition to JUnit 4. For Maven:
The set of test classes in a test suite and the set of parameters the suite defines lead to two alternative execution strategies:
Execute all tests per parameter
Execute each test with all parameters in a row
The current implementation of ParameterizedSuite implements the first strategy, i.e. for each parameter all tests are run before going over to the next parameter. That way instances of parameter objects are handed over from test to test and allow to share state between tests.
Sharing state between tests became especially important in my case for GUI tests: A browser could be set up once and be reused in all tests. That way the session, cookies, current URL and history persisted.
Due to the execution order, only a single parameter instance may be accessed from the ParameterContext at once. During the test suite’s execution the test classes will be instantiated multiple times and, consequently, the method annotated with @Parameters will also be called as often.

Continue reading...