Файл: book-of-vaadin.pdf

Vaadin TestBench

You can re-enable the waiting with enableWaitForVaadin() in the same interface.

23.5.10. Testing Tooltips

Component tooltips show when you hover the mouse over a component. Events caused by hovering are not recorded by Recorder, so this interaction requires special handling when testing.

Let us assume that you have set the tooltip as follows:

//Create a button with a debug ID Button button = new Button("Push Me!"); button.setDebugId("main.button");

//Set the tooltip button.setDescription("This is a tip");

The tooltip of a component is displayed with the showTooltip() method in the TestBenchElementCommands interface. You should wait a little to make sure it comes up. The floating tooltip element is not under the element of the component, but you can find it by

//div[@class='v-tooltip'] XPath expression.

@Test

public void testTooltip() throws Exception { driver.get(appUrl);

//Get the button's element.

//Use the debug ID given with setDebugId(). WebElement button = driver.findElement(By.xpath( "//div[@id='main.button']/span/span"));

//Show the tooltip

testBenchElement(button).showTooltip();

//Wait a little to make sure it's up Thread.sleep(1000);

//Check that the tooltip text matches assertEquals("This is a tip", driver.findElement(

By.xpath("//div[@class='v-tooltip']")).getText());

//Compare a screenshot just to be sure assertTrue(testBench(driver).compareScreen("tooltip"));

}

23.5.11. Scrolling

Some Vaadin components, such as Table and Panel have a scrollbar.To get hold of the scrollbar, you must first find the component element. Then, you need to get hold of the

TestBenchElementCommands interface from the WebElement with testBenchElement(WebElement). The scroll() method in the interface scrolls a vertical scrollbar down the number of pixels given as the parameter. The scrollLeft() scrolls a horizontal scrollbar by the given number of pixels.

23.5.12. Testing Notifications

When testing notifications, you will need to close the notification box.You need to get hold of the TestBenchElementCommands interface from the WebElement of the notification element with testBenchElement(WebElement). The closeNotification() method in the interface closes the notification.

Vaadin TestBench

23.5.13. Testing Context Menus

Opening context menus require special handling.You need to create a Selenium Actions object to perform a context click on a WebElement.

In the following example, we open a context menu in a Table component, find an item by its caption text, and click it.

//Select the table body element WebElement e = getDriver().findElement(

By.className("v-table-body"));

//Perform context click action to open the context menu new Actions(getDriver()).moveToElement(e)

.contextClick(e).perform();

//Select "Add Comment" from the opened menu getDriver().findElement(

By.xpath("//*[text() = 'Add Comment']")).click();

The complete example is given in the AdvancedCommandsITCase.java example source file.

23.5.14. Profiling Test Execution Time

It is not just that it works, but also how long it takes. Profiling test execution times consistently is not trivial, as a test environment can have different kinds of latency and interference. For example in a distributed setup, timings taken on the test server would include the latencies between the test server, the grid hub, a grid node running the browser, and the web server running the application. In such a setup, you could also expect interference between multiple test nodes, which all might make requests to a shared application server and possibly also share virtual machine resources.

Furthermore, in Vaadin applications, there are two sides which need to be profiled: the serverside, on which the application logic is executed, and the client-side, where it is rendered in the browser. Vaadin TestBench includes methods for measuring execution time both on the serverside and the client-side.

The TestBenchCommands interface offers the following methods for profiling test execution time:

totalTimeSpentServicingRequests()

Returns the total time (in milliseconds) spent servicing requests in the application on the server-side. The timer starts when you first navigate to the application and hence start a new session. The time passes only when servicing requests for the particular session.The timer is shared in the servlet session, so if you have, for example, multiple portlets in the same application (session), their execution times will be included in the same total.

Notice that if you are also interested in the client-side performance for the last request, you must call the timeSpentRenderingLastRequest() before calling this method. This is due to the fact that this method makes an extra server request, which will cause an empty response to be rendered.

timeSpentServicingLastRequest()

Returns the time (in milliseconds) spent servicing the last request in the application on the server-side. Notice that not all user interaction through the WebDriver cause server requests.

Vaadin TestBench

As with the total above, if you are also interested in the client-side performance for the last request, you must call the timeSpentRenderingLastRequest() before calling this method.

totalTimeSpentRendering()

Returns the total time (in milliseconds) spent rendering the user interface of the application on the client-side, that is, in the browser.This time only passes when the browser is rendering after interacting with it through the WebDriver. The timer is shared in the servlet session, so if you have, for example, multiple portlets in the same application (session), their execution times will be included in the same total.

timeSpentRenderingLastRequest()

Returns the time (in milliseconds) spent rendering user interface of the application after the last server request. Notice that not all user interaction through the WebDriver cause server requests.

If you also call the timeSpentServicingLastRequest() or totalTimeSpentServicingRequests(), you should do so before calling this method. The methods cause a server request, which will zero the rendering time measured by this method.

Generally, only interaction with fields in the immediate mode cause server requests.This includes button clicks. Some components, such as Table, also cause requests otherwise, such as when loading data while scrolling. Some interaction could cause multiple requests, such as when images are loaded from the server as the result of user interaction.

The following example is given in the VerifyExecutionTimeITCase.java file under the TestBench examples.

@Test

public void verifyServerExecutionTime() throws Exception { openCalculator();

// Get start time on the server-side

long currentSessionTime = testBench(getDriver())

.totalTimeSpentServicingRequests();

//Interact with the application calculateOnePlusTwo();

//Calculate the passed processing time on the serve-side long timeSpentByServerForSimpleCalculation = testBench()

.totalTimeSpentServicingRequests() - currentSessionTime;

//Report the timing

System.out.println("Calculating 1+2 took about "

+timeSpentByServerForSimpleCalculation

+"ms in servlets service method.");

//Fail if the processing time was critically long if (timeSpentByServerForSimpleCalculation > 30) {

fail("Simple calculation shouldn't take "

+timeSpentByServerForSimpleCalculation + "ms!");

}

//Do the same with rendering time

long totalTimeSpentRendering = testBench().totalTimeSpentRendering();

System.out.println("Rendering UI took " + totalTimeSpentRendering + "ms");

if (timeSpentByServerForSimpleCalculation > 400) {

Vaadin TestBench

fail("Rendering UI shouldn't take "

+ timeSpentByServerForSimpleCalculation + "ms!");

}

// A regular assertion on the UI state assertEquals("3.0", getDriver().findElement(

By.id("display")).getText());

}

23.6. Taking and Comparing Screenshots

You can take and compare screenshots with reference screenshots taken earlier. If there are differences, you can fail the test case.

23.6.1. Screenshot Parameters

The screenshot configuration parameters are defined with static methods in the com.vaadin.testbench.Parameters class.

screenshotErrorDirectory (default: null)

Defines the directory where screenshots for failed tests or comparisons are stored.

screenshotReferenceDirectory (default: null)

Defines the directory where the reference images for screenshot comparison are stored.

captureScreenshotOnFailure (default: true)

Defines whether screenshots are taken whenever an assertion fails.

screenshotComparisonTolerance (default: 0.01)

Screen comparison is usually not done with exact pixel values, because rendering in browser often has some tiny inconsistencies. Also image compression may cause small artifacts.

screenshotComparisonCursorDetection (default: false)

Some field component get a blinking cursor when they have the focus. The cursor can cause unnecessary failures depending on whether the blink happens to make the cursor visible or invisible when taking a screenshot. This parameter enables cursor detection that tries to minimize these failures.

maxScreenshotRetries (default: 2)

Sometimes a screenshot comparison may fail because the screen rendering has not yet finished, or there is a blinking cursor that is different from the reference screenshot. For these reasons, Vaadin TestBench retries the screenshot comparison for a number of times defined with this parameter.

screenshotRetryDelay (default: 500)

Delay in milliseconds for making a screenshot retry when a comparison fails.

For example:

@Before

public void setUp() throws Exception { Parameters.setScreenshotErrorDirectory(

"screenshots/errors");

Parameters.setScreenshotReferenceDirectory(

"screenshots/reference");

Parameters.setMaxScreenshotRetries(2);