Over a million developers have joined DZone.

How to Use Golden Masters to Check Web Apps With recheck

DZone 's Guide to

How to Use Golden Masters to Check Web Apps With recheck

Check everything at once and create unbreakable tests.

Free Resource

Check everything at once and create unbreakable tests. recheck is a Golden Master-based, open-source test framework on top of Selenium that comes with powerful features. Let's take a closer look.


  • Easy creation and maintenance of checks for web
  • Semantic comparison of contents
  • Easily ignore volatile elements, attributes, or sections
  • One-click maintenance to update Golden Masters with intended changes
  • No unexpected changes go unnoticed
  • Operates on top of Selenium
  • Makes your tests unbreakable
  • The Git for your GUI


Instead of manually defining individual aspects that you want to check, check everything at once. So instead of writing many assert statements — and still not have complete checks — write a single re.check(). This saves a lot of effort when creating tests. And it makes sure to not miss unexpected changes.

Even better: using the ReTest GUI (or the soon-to-come open-source CLI), you can easily accept those changes with a single click (patent pending). This also saves a lot of time during maintenance. Moreover, any regular changing aspects or elements (e.g. date fields) can easily be ignored.

And, using the Golden Master, recheck can identify elements even after the identifying attribute was changed. So assume you are using an HTML id property to identify an element within your Selenium test. Now, assume that this idproperty changes within the HTML. Then, your test would break, resulting in an NoSuchElementException. But using RecheckDriver as a drop-in replacement/wrapper of your normal driver magically finds the element and logs a warning such as:

*************** recheck warning ***************
The HTML id attribute used for element identification changed from 'intro-slider' to 'introSlider'.
retest identified the element based on the persisted old state.
If you apply these changes to the state , your test  will break.
Use `By.id("introSlider")` or `By.retestId("9c40281d-5655-4ffa-9c6d-d079e01bb5a3")` to update your test.


recheck operates on top of Selenium. Selenium has become an official W3C standard, supported by all major browsers. Learn more about Selenium and how to install it here.

recheck is available as a Java API with support for JUnit 4 and JUnit 5, as well as TestNG.


Add recheck-web as a dependency through Maven Central:

  <version><!-- latest version, see above link --></version>

Usage of Plain recheck

Then, replace the assertions in your Selenium test. An example test could look like so (simplified):

public class MyRecheckWebTest {

  private WebDriver driver;
  private Recheck re;

  public void setUp() {
    driver = new ChromeDriver();

    // Use the default implementation.
    re = new RecheckImpl();

  public void index() throws Exception {
    // Set the file name of the Golden Master.
    re.startTest( "my-file-name" );

    // Do your Selenium stuff.
    driver.get( "https://my-url.org/" );

    // Single call instead of multiple assertions (doesn't fail on differences).
    re.check( driver, "my-step-name" );

    // Conclude the test case (fails on differences).

  public void tearDown() {

    // Produce the result file.

Running such a test for the first time will result in the failure with an output like below:

java.lang.AssertionError: Found 1 differences in 1 checks of which 1 are unique: [No recheck file found.]

test simple-showcase has 1 differences (1 unique): 
No recheck file found. First time test was run? Created recheck file now, don't forget to commit...

at de.retest.recheck.RecheckImpl.capTest(SourceFile:135)
at de.retest.web.it.SimpleRecheckShowcaseIT.index(SimpleRecheckShowcaseIT.java:61)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

Running such a test will also create a folder structure containing a retest.xml file and a screenshot per check (depending on your chosen names and configuration). These are now the Golden Master, the baseline in which future executions of this test are compared with. If you use version control, you should commit those files. Note that the retest.xml contains a full description of the rendered website, including all relevant information such as text, source, etc, and all non-default CSS attributes, such as font and margin. Although these files may become large, they are smaller than the original, and by ignoring specific (or all) attributes, you can configure how large they are. Anyways, storing a few kilobyte extra is much cheaper than the manpower needed to manually specify checks.

Executing the same test again should not result in any differences. But after changing the website and executing the test, you should see the test reporting your changes.

If you change a single CSS rule, you will find all elements that are affected by this change, like so:

java.lang.AssertionError: Found 8 differences in 1 checks of which 2 are unique: [color: expected="rgb(65, 65, 65)", actual="rgb(0, 0, 0)", border-color: expected="rgb(65, 65, 65)", actual="rgb(0, 0, 0)"]

test showcase has 8 differences (2 unique): 
index resulted in: 
EM [Have you had enough]:
border-color, color: expected="rgb(65, 65, 65)", actual="default"
EM [Use an artificially intelligent]:
border-color, color: expected="rgb(65, 65, 65)", actual="default"
EM [to fully automatically test your application.]:
border-color, color: expected="rgb(65, 65, 65)", actual="default"
EM [No need to create assertions]:
border-color, color: expected="rgb(65, 65, 65)", actual="default"
EM [retest compares the whole picture instead of a single piece of the puzzle.]:
border-color, color: expected="rgb(65, 65, 65)", actual="default"
EM [The future of testing is in AI.]:
border-color, color: expected="rgb(65, 65, 65)", actual="default"
EM [The future of testing is now]:
border-color, color: expected="rgb(65, 65, 65)", actual="default"

Additionally, a file named replay.result will be created upon test failure, which is typically located in your target/test-classesfolder. This file can now be used to apply those changes to your baseline, using either the recheck-cli or the retest-GUI.

Usage of RecheckDriver/ "Unbreakable Selenium"

In order to use "Unbreakable Selenium," you just need to wrap your usual driver within a RecheckDriver (drop-in replacement) and use RecheckWebImpl instead of RecheckImpl. The code would the look like so):

 // Use the RecheckDriver as a wrapper for your usual driver.
 driver = new RecheckDriver( new ChromeDriver() );

 // Use the unbreakable recheck implementation.
 re = new RecheckWebImpl();
selenium ,gui ,retest ,recheck ,golden masters ,css ,html ,open source ,regression testing ,testing framework

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}