Test suite configuration

This page lists a set of configuration settings, i.e. methods of the configuration class that are commonly used to set up visual tests in a test suite.

All of these methods must be called before the call to eyes. eyes$open. If called after eyes$open, then it has no effect on the current session, but will be used if another session is opened on that eyes instance afterwards.

Click on the name of the method to see the full details.

configuration$setapikey This method allows you to provide your API KEY explicitly in the code. You can also pass the API KEY to the SDK by assigning its value to the environment variable APPLITOOLS_API_KEY. For more, for more information on how to obtain your API key see How to obtain your API key.
configuration$setbatch All the tests that run using a runner such as the visualgridrunner are collected into a batch in the Eyes Test Manager. Create a configuration$setbatch object with the name of the batch, optionally set the batch sequence name and then pass the object to this method. For more information about batches see How to organize your tests with batches.
configuration$setserverurl If you use a private Eyes cloud or on an Eyes premise server, then you should call this method, passing it the URL of your Eyes server.
configuration$setAppName A test is identified uniquely by its application name and test name. If all the tests in this run use the same application name, then it is convenient to set it once in one place. Each test must then be given a unique test name as described below.
configuration$setViewportSize

This defines a default viewport size of the test client browser.

The client browser is the browser that your Selenium code interacts with. The Eyes SDK uses it when you call one of the eyes check method to extract the DOM that it sends to the Ultrafast Grid. This DOM is used to generate all the checkpoints for all the browser configurations, so you need to ensure that the DOM created is independent of the viewports used by the browser configurations. For example, if JavaScript runs on the page on the local client, then it should not assume that the browser viewport size is the viewport size that will be actually rendered, since this could be different for the various browser configurations.