Try it out

In this tutorial, we'll show you how to build your own Selenium test suite by leveraging selenium-tinafw.

Setup

Thanks to selenium-tinafw-archetype, it is very easy to get started.

mvn archetype:generate -Dfilter=me.alb-i986.selenium:selenium-tinafw-archetype

This provides you with a skeleton project, ready to be customised to suit your own SUT.

Please see also the README of selenium-tinafw-archetype.

Configuration

Two config files, required by the framework, are provided:

• src/test/resources/config.default.properties
• src/test/resources/config.custom.properties

The properties contained in config.custom.properties will override the ones in config.default.properties. Therefore config.default.properties should be added to your VCS, while config.custom.properties shouldn't.

A couple of properties that you may want to amend are:

• tinafw.base_url: the base URL of the SUT
• tinafw.browsers: the list of browsers that the tests need to be run on

Customisations

Now it's time to start writing the code specific to your own SUT: page objects, tasks, tests.

For a start, please see:

• the sample provided in the package sample, containing a small but full working example of use

Javadocs can be found at http://alb-i986.github.io/selenium-tinafw/javadoc/

Page objects

When developing page objects, try to design them with a fluent interface in mind, as much as possible.

For example, say you have a form with a submit button. After you click submit, a dialog pops up asking the user to confirm.

submitBtn.click() // after submitting, a confirmation dialog will pop up
new ConfirmDialog(driver, this) // the constructor implicitly waits until the page object is displayed
  .confirm() // click the 'yes' button 
;

public class ConfirmDialog extends BaseWebPage {

  @FindBy(id = "confirm")
  private WebElement confirmBtn;
  
  [..]
  
  public void confirm() {
    confirmBtn.click();
  }
}

Please note that ConfirmDialog#confirm returns void: in fact, after confirming, the dialog closes.

Tasks

Each of your custom tasks should extend BaseWebTask, or NavigationWebTask. The latter is for tasks that perform a navigation step, i.e. browsing to some page.

If your SUT provides a login functionality, you should define a class ImLoggedIn, to extend ImLoggedInBase, and define an implementation for #loginPageClass.

Tests

See Tests.

Final recommendation

We recommend developing outside-in. That is, start from writing the test method, and let the IDE help you making your way through tasks to pages.