Testing web pages without writing code

Since version 1.11.0 ecFeed (the Eclipse plugin and also the standalone application) has an ability do run web pages tests without implementing any code. It opens a selected browser on a tested web page (the browser and address can be parameterized) and stimulates page’s elements with actions that are mapped to method parameters.


Before running this tutorial, you should make sure that have installed Chrome and Firefox web browsers in your system.
You also need to go to selenium web page and download selenium drivers for these browsers. The drivers are created and maintained by third parties. For installation instructions refer to the manual of the specific driver.
You should be also familiar with the basic features of ecFeed.

Opening browser on a custom page

This test will show how to open a browser on a custom web page and check its title. We will use the Flight Finder 2 application. It is an example web site, which displays flights according to selected airports and range of dates.

Start ecFeed as an Eclipse plugin or a standalone version.
Add a test class to the model and a testFlightFinder2 method to the class.
In the method’s details page, select Web runner in the Runner combo.
Now select Chrome in the Browser combo box.
In the field Web driver type path to the Selenium Chrome driver (a full path to a folder where the driver was unziped including name of the driver).
In the field Start URL type URL of the web page: http://ecfeed.com/samples/FlightFinder2/.

Now press the Test online… button. EcFeed will open the Chrome browser on the requested site. The browser is immediately closed down.
It may be delayed by adding a numeric (integer, float etc.) parameter named delay to the method and setting it’s element type do Delay[s]. Let’s do it and then add one choice for this parameter that will determine delay in seconds.
Then press the “Test online… button and then OK on the popping dialog. Now the web page should be seen longer before closing down.

Checking a page title

Let’s now check if the page title is correct.
Add a String parameter to the method and name it pageTitle.
In the parameter’s details page check Expected checkbox.
As the default value for the expected parameter type: Flight Finder 2.
In the Web runner properties section select Element type: Text.
In the field Identified by select: Id.
In the next field type: pageTitle. This indicates to ecFeed, that the parameter is mapped to a text element on the page that is identified by id pageTitle. The delay parameter can be moved down to be the last parameter (use the Move Down option selected from the context menu).
Now go back to the method testFlightFinder2‘s details page and click Test online button.

Manipulating page’s elements

Now, let’s manipulate the page’s elements. Add to the testFlightFinder2 method the following parameters:

  • airportFrom of type String.
    Element type: Select.
    Idenfified by Id and airportFrom.
    Add one choice of value FRA.
  • airportTo of type String.
    Element type: Select.
    Idenfified by Id and airportTo.
    Add one choice of value ATL.
  • oneWayRadioButton of type String.
    Element type: Radio.
    Idenfified by Name and direction.
    Add one choice of value directionOneWay.
  • flyOutDate of type String.
    Element type: Text.
    Idenfified by Id and flyOutDate.
    Add one choice of value 2017-05-01.
  • searchFlightsButton of type boolean.
    Element type Button.
    Identified by Id and searchFlightsButton.
    Add one choice of value true.

Make sure that the delay parameter is positioned between flyOutDate and searchFlightsButton parameters. This will cause that the execution will pause a bit after setting all the inputs in the form and before pressing button. It will allow us to see that the form is actually filled as we wanted. We can add an another numeric (integer) parameter delay2 at the last position and map it to a Delay type, to see the result of pressing the button.

Now press the Test Online… button and see what happens. The fields in the Flight Finder 2 page should be set to corresponding values and after a while a page with results should appear. The test execution moved us to a new address.

It is worth to check if the address is the same as we expected.
To do that, add a new expected String parameter called resultUrl.
Remember to place it after the searchFlightsButton and delay2 parameters.
Set its element type to Page URL.
The default value should be set to http://ecfeed.com/samples/FlightFinder2/results.html.
Test execution will now check if the result URL is correct.

Check elements created dynamically

We can define expected parameters that check values that were created dynamically during test execution. Let’s check the value of a label that exists on the “Results” page.
Add a String parameter named maxPriceLabel.
Mark it as expected and set its default value to Max prize:.
Set the element type to Text and make it identified by id maxPriceLabel.
Execute the test. It should fail with a communicate that an expected text does not match. Indeed, we made a typo in the parameter’s default value.
Change it to Max price: and rerun the test. Now it should go fine.

Optional page elements

Let’s now test how the page works if we provide it with an incorrect input.
Add a new choice to oneWayRadioButton.
Name it return and set the value to directionReturn.
Add a new parameter returnDate of a String type.
Set the element type to Text.
Make it identified by Id and returnDate.
Add one choice with the value 2017-05-15.
Move the parameter after flyOutDate.
Execute the test.

One of two test cases should fail because the choice named return of parameter oneWayRadioButton causes the web page field ‘Return date’ to be hidden. As a result, its value can not be set.
Now go to returnDate parameter and select Optional checkbox.
Execute the test. The test should pass now. The Optional checkbox will cause that the element that is mapped to the parameter will be modified or checked only if it exists on the page. If not, the parameter is ignored.

The Optional checkbox can be used together with Expected parameter. In this case the element type should be Text. The test does not fail when page element is not found, or it is found but its value can not be set (is hidden or disabled),

Using various browsers

We can test how our web page behaves for various browsers – in our case: Chrome and Firefox.
Go to the method page and select checkbox Map browser to method parameter in the Web runner section.
Add a parameter browser of the String type. Set the Element type to Browser. Add choices:
Name Chrome, for the Value type the path to the chrome driver.
Name Firefox, for the Value type the path to the gecko driver (the driver for Firefox).
Move the browser parameter to be the the first method’s parameter.
Perform the test. It should run 4 test cases, two of them with the use of Chrome web browser and two of them with the use of Firefox.

Parametrized URLs

We can perform the test using various start URLs. This feature can be useful for example if we want to pass parameters in the address of the web page.
Add a testUrls method to the test class. Select WebRunner, Browser and enter Web driver path.
Check the Map start URL to method parameter checkbox.
Add a parameter startPage of a String type. Set the Element type to Page URL.
Add a choice Name address1, Value: http://ecfeed.com/samples/FlightFinder2/error.html?msg=Message 1.
Add a choice Name address2, Value: http://ecfeed.com/samples/FlightFinder2/error.html?msg=Message 2.
Add a parameter errorMessage of String type. Mark the parameter as expected. Set the Element type to Text. Set Identified by Id and errorMessage.
Add constraint – if: startPage=address1, then: errorMessage=Message 1.
Add constraint – if: startPage=address2, then: errorMessage=Message 2.
Run the test.

The web page error.html parses the msg parameter from the page address and sets the text of the html element
<td id="errorMessage"></td>.
This text is then compared the value of the expected parameter. Constraints assure that the expected value is linked to the corresponding page address.

Defining web driver path

A web driver path must match the type of browser used. For example for web browser Chrome, the path to driver (on Linux) could look like:
Instead of writing the whole path, an user defined environment variable can be used to partly define the path. For example if we define an environment variable SELENIUM_WEBDRIVERS as /home/userX/SeleniumWebDriver then web driver path can be written as: %SELENIUM_WEBDRIVERS%/Chrome/chromedriver.
This solution is convenient when different people use the same ecFeed model file. Each user can have a different path to the web drivers.

Detailed description of web elements and actions can be found in the documentation section: ‘Automated web testing’.