Use standard AsciiDoc syntax for source code blocks

documentation/testbench-advanced-testing-concepts.asciidoc

@@ -24,17 +24,19 @@ In most cases, this is not something you need to take into account as waiting is
 `TestBenchCommands` interface. You can call it in a test case as
 follows:
 
-```java
+[source, java]
+----
 testBench(driver).disableWaitForVaadin();
-```
+----
 
 When disabled, you can wait for the rendering to finish by calling
 `waitForVaadin()` explicitly.
 
 
-```java
+[source, java]
+----
 testBench(driver).waitForVaadin();
-```
+----
 
 
 You can re-enable the waiting with `enableWaitForVaadin()` in the
@@ -49,9 +51,10 @@ is met. This could, for example, be used to wait until an element is visible on
 the web page.
 
 
-```java
+[source, java]
+----
 waitUntil(ExpectedConditions.presenceOfElementLocated(By.id("first")));
-```
+----
 
 The above waits until the specified element is present or times out after
 waiting for 10 seconds by default.
@@ -126,7 +129,8 @@ The following example is given in the
 file in the TestBench demo.
 
 
-```java
+[source, java]
+----
 @Test
 public void verifyServerExecutionTime() throws Exception {
     // Get start time on the server-side
@@ -167,4 +171,4 @@ public void verifyServerExecutionTime() throws Exception {
         $(TextFieldElement.class).first()
         .getValue());
 }
-```
+----

documentation/testbench-bdd.asciidoc

@@ -35,7 +35,8 @@ link:https://github.com/vaadin/testbench-demo/blob/master/src/test/java/com/vaad
 test class]:
 
 
-```java
+[source, java]
+----
 public class CalculatorSteps extends TestBenchTestCase {
     private WebDriver driver;
     private CalculatorPageObject calculator;
@@ -67,7 +68,7 @@ public class CalculatorSteps extends TestBenchTestCase {
         assertEquals(result, calculator.getResult());
     }
 }
-```
+----
 
 The demo employs the page object defined for the application UI, as described in
 <<dummy/../testbench-maintainable-tests-using-page-objects#,Creating Maintainble Tests using Page Objects>>.

documentation/testbench-ci-server.asciidoc

@@ -28,9 +28,10 @@ If you have an external server that you deploy the application to, you will typi
 In tests you typically use an URL like `http://localhost:8080/` when running on your local machine. On a build server this is usually ok if you are running the server and the tests all on the same build agent. 
 
 If only the server is running on the build agent and the browsers are running on a separate machine or on a cloud based browser provider, you might need to define and use a public IP of the build agent. Either you need to pass the IP address to the build in some way and use it in your test, or you can use the provided `IPAddress.findSiteLocalAddress()` helper in your test as e.g.
-```java
+[source, java]
+----
 getDriver().get("http://" + IPAddress.findSiteLocalAddress() + ":8080/");
-```
+----
 
 If you are deploying on another host name, you need to pass that information to the tests in a suitable way, e.g. as a system property or environment variable you read in the test code.
 
@@ -48,18 +49,20 @@ In addition to installing the browsers on the build agent, you must take into ac
 2. If it is a Linux based system, start `xvfb` which provides a GUI environment for the browser without actually showing the GUI environment anywhere.
 
 To run Chrome in headless mode, you need to pass the `--headless` (and `--disable-gpu` on Windows) parameter to the `ChromeDriver` when starting the browser. The parameters can be defined using `ChromeOptions`:
-```java
+[source, java]
+----
 ChromeOptions options = new ChromeOptions();
 options.addArguments("--headless", "--disable-gpu");
 setDriver(new ChromeDriver(options));
-```
+----
 
 Similarly, to run Firefox in headless mode, you need to pass the `-headless` parameter to the `FirefoxDriver`:
-```java
+[source, java]
+----
 FirefoxOptions options = new FirefoxOptions();
 options.addArguments("--headless", "--disable-gpu");
 setDriver(new FirefoxDriver(options));
-```
+----
 
 [NOTE]
 The `--disable-gpu` flag is only needed on Windows and until http://crbug.com/737678 is resolved but it should not hurt on other platforms.
@@ -77,16 +80,16 @@ If you are not resetting the database for each test, you should typically not ru
 [[testbench.ci-server.license]]
 == Installing the License
 The license for your subscription is stored on your local machine in
-```
+----
 ~/.vaadin/proKey (Mac/Linux)
 %HOMEPATH%\.vaadin\proKey (Windows)
-```
+----
 You need to copy the file from your local machine to the CI server to enable running tests on the CI server. The CVAL3 license allows you to use your personal license on the CI server also. This is the preferred way as it will always make the license available to all builds running on the same server.
 
 If you do not have access to the build agent running your builds on the CI server, you can also supply the license information using a system property:
-```
+----
 -Dvaadin.proKey=<username>/<proKey>
-```
+----
 where the `username` and `proKey` values come from your local `proKey` license file. 
 
 [NOTE]

documentation/testbench-creating-tests.asciidoc

@@ -26,32 +26,36 @@ An `ElementQuery` is what is used to find a given `Element` (component) on the p
 
 Consider the following query:
 
-```java
+[source, java]
+----
 List<ButtonElement> buttons = $(ButtonElement.class).all();
-```
+----
 
 The query returns a list of HTML elements of all the `Button` components in the UI. The buttons found by the query could be controlled, for example, by clicking them as:
 
-```java
+[source, java]
+----
 for (ButtonElement button : buttons)
     button.click();
-```
+----
 
 [[testbench.creatingtests.elementquerymethods]]
 == Element Query Methods
 
 The `$` method creates an `ElementQuery` that looks for the given element class. The method is available both for `TestBenchTestCase` (searches the whole current page) and in `TestBenchElement` (searches inside the given element).
 
-```java
+[source, java]
+----
 // Find the button with id="ok"
 ButtonElement button = $(ButtonElement.class).id("ok");
-```
+----
 
-```java
+[source, java]
+----
 // Find the first label inside the layout with id="content"
 VerticalLayoutElement layout = $(VerticalLayoutElement.class).id("content");
 LabelElement label = layout.$(LabelElement.class).first();
-```
+----
 
 [NOTE]
 If there is no suitable element class available, you can also use the `$("tag-name")` method to find an element of a given type.
@@ -73,15 +77,16 @@ You can use the `ElementQuery` instance returned by `$()` to refine the search q
 
 Using Element Queries and Elements you can now compose test methods like:
 
-```java
+[source, java]
+----
 @Test
 public void fillForm() {
     $(TextFieldElement.class).id("firstName").setValue("John");
     $(TextFieldElement.class).id("lastName").setValue("Doe");
     $(ButtonElement.class).id("ok").click();
     Assert.assertEquals("Thank you for submitting the form", $(DivElement.class).id("result"))
 }
-```
+----
 
 Do be aware that if you write tests in this manner, you will have a hard time maintaining the tests. A good way to stucture tests is to have only the high level logic in the test itself (your manager should be able to read and understand the test method) and extract the `ElementQuery` parts to a separate *Page Object* class. See <<dummy/../testbench-maintainable-tests-using-page-objects.asciidoc#
 ,Creating Maintainble Tests using Page Objects>> for more information.

documentation/testbench-getting-started.asciidoc

@@ -13,12 +13,13 @@ If you just want to test out TestBench and see how tests are run, the easiest wa
 [[testbench.quickstart.dependency]]
 == Setting up your Project
 To start using TestBench in an existing project, you need to add the TestBench dependency (`com.vaadin`/`vaadin-testbench`) with a `test` scope. Assuming you have imported the Vaadin platform BOM and have a Maven project, all you need to do is add:
-```xml
+[source, xml]
+----
 <dependency>
     <groupId>com.vaadin</groupId>
     <artifactId>vaadin-testbench</artifactId>
 </dependency>
-```
+----
 The `test` scope and version number is predefined by the Vaadin BOM.
 
 To be able to run tests locally, you might need to install a webdriver for your browser, see  <<dummy/../testbench-installing-webdrivers#,Installing Web Drivers>> for more details.
@@ -37,7 +38,8 @@ The following test example will perform all the above tasks with the test logic
 
 In the Maven world, all test classes live in the `src/test/java` directory. Create a new class called `SimpleIT` in that directory (`IT` stands for *integration test* and Maven will automatically run all `*IT` classes):
 
-```java
+[source, java]
+----
 import org.junit.After;
 import org.junit.Assert;
 import org.junit.Before;
@@ -72,7 +74,7 @@ public class SimpleIT extends TestBenchTestCase {
     }
 
 }
-```
+----
 
 This is all you need to verify that the text of the button is "Clicked" after clicking on it.
 
@@ -86,18 +88,18 @@ Don't place your tests in the root package as in this example. Structure them lo
 The server hosting your application needs to be running at the given URL before you launch your test. If the server is already running and the application is deployed, you only need to ensure that the URL in the test is correct.
 
 If you are using the Spring Boot starter at https://vaadin.com/start/lts/project-base, you can launch the application using 
-```
+----
 mvn spring-boot:run
-```
+----
 If you are using a plain Java Servlet starter, you can launch the application using
-```
+----
 mvn jetty:run
-```
+----
 
 You can now launch your test in your IDE (run as JUnit test) or in another terminal:
-```
+----
 mvn verify
-```
+----
 
 You should see a browser window opening, doing something and then closing. If the test fails, put a breakpoint in the `clickButton` method so you can see what happens in the browser before it closes.
 

documentation/testbench-low-level-element-interactions.asciidoc

@@ -14,25 +14,27 @@ Typically you use the provided, high level element API to interact with componen
 == Getting or Setting Properties
 Many interactions with web components can be done by reading or modifying element properties. For this, the following helpers are provided in `TestBenchElement`:
 
-```java
+[source, java]
+----
 String getPropertyString(String... propertyNames)
 Boolean getPropertyBoolean(String... propertyNames)
 Integer getPropertyInteger(String... propertyNames)
 Double getPropertyDouble(String... propertyNames)
 Object getProperty(String... propertyNames)
 TestBenchElement getPropertyElement(String... propertyNames)
 List<TestBenchElement> getPropertyElements(String... propertyNames)
-```
+----
 
 These methods are typically meant for creating __page objects__ or TestBench elements but can also be handy as a workaround when a needed method is not available.
 
 Typically you should use the correct `getPropertyXYZ` depending on the type of the property in JavaScript. If you use another type, the value will be converted using standard JavaScript rules (which may or may not give the result you desire).
 
 == Calling Functions
 If you need to call a function on an element, you can use `Object callFunction(String methodName, Object... args)` available in `TestBenchElement`, e.g.
-```java
+[source, java]
+----
 divElement.callFunction("setAttribute", "title", "Hello");
-```
+----
 
 
 == Executing JavaScript
@@ -41,10 +43,11 @@ to execute a JavaScript snippet to accomplish your task. You can excute any Java
 method are available through the `arguments` array in JavaScript.
 
 For example to return the `offsetHeight` property of an element you could do
-```java
+[source, java]
+----
 TestBenchElement element = ...; // find the element somehow
 Long offsetHeight = (Long)executeScript("return arguments[0].offsetHeight", element);
-```
+----
 
 [NOTE]
 The above `executeScript` call would be the same as using `element.getPropertyInteger("offsetHeight");`.