What problems do you meet, when you first want to create your project to write automation tests for your web-based application? We think the most popular are:

  • what should be the architecture of project?
  • how to create simple test?
  • how to run and work with browser?
  • what libs and dependencies should I add to my project to make it work correct?

Now, with our beautiful plugin, you can think about where you will watch football match today and forget about described questions! We created simple project with all what you need to create your first selenium tests.

In next sections you could find more information about how to create project, what main parts does it have and how to start your first test. All these manipulations will need from you about 5 minutes or maybe less.

How to create? 

For using our awesome features,  first you must install a plugin to your IntelliJ IDEA(you could see how to do it at the beginnig of this article).

After successful install select File -> New Project -> Java -> Next and you'll see this element:

When you select it - in the right pane you’ll some fields for configure your project name, project location and project SDK.
Configure these fields and click “Finish” button . After these simple steps, in opened windows you will see ready for work project! Thats all you need to start! Is it cool? We think - YES.

What could I see in project?

Now you could have one question - what was done when I click this “Finish” button?
Answer is near. You create simple maven-based project with all preconfigured and ready for use features.

Some note: In you have no maven on your computer - now it is time to install it. For this you could visit maven site(http://maven.apache.org/index.html) Without maven - you could not build your project. And also - maven is very cool instrument!

The main parts of your projects are:

  • file pom.xml - configuration file for configure dependencies, build and run your project
  • ’main’ directory - it contains objects you will use in your tests
  • ’test’ directory - contains all your tests

Now let’s talk about all these components in more details.

pom.xml

You have ready for use configuration file with all dependencies you’ll need to start developing and run your Selenium tests.

In this file you could see next sections:

  1. <groupId>com.selenium.test</groupId> - there is an a group id of your tests. This is the part of your tests project indentification name. With this id your colleagues could use your project and import it to their projects.
  2. <artifactId>selenium-app</artifactId> - artifact id. This is the second part of your tests project id
  3. <version>1.0-SNAPSHOT</version> - this is your current project version.

All these 3 id’s - groupId, artifactId and version - are the part of your project “big id”. By combination of this id’s everyone can identify your project

  1. <properties> section - there you can put properties that you use in your pom.xml. Often it is uses for store versions of used libraries. For using one of properties - just insert there tag with name of your setting and value between opening and closing tag. After that - anywhere in pom.xml you could use your property in such manner: ${property_name}
  2. <build> and <plugins> sections - there you can put your using for your project plugins descriptions and configurations. Now there is one plugin, which describes the version of your java, which will be used for project
  3. <dependencies> - the most often used section of pom.xml. There you could add libraries dependencies to your project. In our project there are 3 main dependencies:

               a)junit - for using JUnit test framework(official site)
               b)testNG - for using TestNG test framework(official site)
               c)selenium - for using selenium specified libs(official site)


Combination of these 3 libs - all you need for your first tests creation! After, in future, you will add more dependencies, but now - these 3 are enough.

'main' directory.

The heart of this project. It contains base classes and utilities, needed for tests creation.
Let’s look on each block of this directory in details:
1)‘configuration’ package.
This package contains main configuration class - TestConfig. It needs to read and store global properties for tests, such as browser version, base url for tests and so on. In this class you can see such strings:           

@Property("browser.name")
private String browser = "firefox";

This is configuration of browser for tests. There you could see annotation with name of property in braces. When running tests, system property with such name will be readed and variable value will be setted to this property value.

NOTE: to set system variable you could do one of these:
from IntelliJ IDEA: Run/Debug configuration -> VM options - set property in such way: -DpropertyName=propertyValue(for example for browser name : -Dbrowser.name=firefox) 
from command line: add to command line parameters it this way: -DpropertyName=propertyValue(for example for browser name : -Dbrowser.name=firefox)

If you want this variable to have a default value - just init it(such as we did it in TestConfig with browser name). If variable is inited - system property also will be readed, and, if value was founded, variable will be reinitialized.

Also you have an opportunity to read properties values from .properties files. For this, you should add annotation PropertyFile to class:

@PropertyFile("config.properties")
public class TestsConfig {}

If such annotation exist - all properties will be read from file with such name from resources folder of project.

Also this package contains utility classes for reading properties in TestConfig(such ad @Property and @PropertyFile annotation  and PropertiesLoader class, who did all work in properties initialisation process)

2)’utils’ package.
This package for some utilities classes. In our project it contains TimeUtils class needed for some operations with time(such ad wait). In future, you’ll add here some cool classed to make your project awesome.

3)'exceptions' package.

This package uses for some user defined exception classes
3)’webtestsbase’ package.
The heart of the heart of our project. There you can find base classes for interaction with browser and web driver and some other very important classes for web tests creation. Let’s describe these classes:
BasePage - main class for creation test based on Page Object pattern. When you use this pattern - you’ll create many page classes. All these classes you must extend from BasePage. In this base class there are some cool and important functions, such as initialisation of pages elements and page opening wait.


When you extend this class - you must realize 2 methods in your class: openPage() - there you’ll put logic, that will be called if you want to open your page with some url; isPageOpened() - there is method, that must return some indicator, shows us that page is opened(for example - displaing of some element)


Also BasePage class has constructor with parameter boolean openPageByUrl.
If you want to open page by some url - you must set this arg to true. If it will be true - then openPage() will be called.
You now could think - wtf? Why there is this parameter? We have answer. Instantiation of pages could be in 2 ways: when you just simple open page by url with new YourPage(). In this case - you could create in your page class default constructor and call super(true) from it. Then openPage() will be called.


But there could be another situation - you press some button and some page is opened. In this case you don’t need openPage() method call. In this case you could create default constructor with super(false) call. Also you could create constructor with parameter in your class and call super constructor with this parameter.


Also BasePage class contains method waitForOpen(), which check, if the page is opened(through call isPageOpened() method of your page class and waiting)


And finally - method getDriver(). When you want to use driver-specific features in your pages - use this method to interact with web driver. In this case - you’ll always have only one instance of web driver in your tests and no other instance will be created while tests run. 

Browser - enum contains browser names. This class contains all supported in project browsers. When you want to select browser for tests - your ‘browser.name’ system property should be set to one of this enum values. If no - you will see an exception at the start of your tests.

CapabilitiesGenerator - class for capabilities creation. When you create your web driver instance - you must add DesiredCapabilities object as parameter to WebDriver constuctor. These capabilities contains some settings needed for browser instantiation. Also you could put in this capabilities your configs for browser(some properties for new browser profile). You could read about it here. In our class - we generate default, base capabilities for browser start.

Важно: for chrome driver you must spicify system property webdriver.chrome.driver (you could see description here). If property is not set - an error will be thrown at start.

WebDriverFactory - main class for work with web driver. All work with web driver MUST be done through this class. It contains WebDriver instance (as singletone), and has 3 main methods:
startBrowser(boolean isLocal). You must call it when you want to start browser from your tests. If you call it, but browser already had been started - exception about it will be thrown. This method contains argument - isLocal. When you start your tests local on your machine without using grid(you could read about grid and how to use it here), you must set this argument to true. Otherwise - it must be set to false.

finishBrowser(). You should remember this one of the main rules of web tests creation - close browser when you finish your interactions with it(don’t forget about closing when errors occurred). In our project - use this method for closing browser.

getDriver(). All interactions with web driver from your tests must be done through this method. If it is in such way - you could be sure that you will never use more than one instance of web driver. If you do not - some really bad things may occured.

takeScreenshot() - method for screenshot taking. We specially left it empty because we don't know, how  you save and store your screenshots.

That’s all about this directory for now. We believe, that in future you’ll add many cool features(packages and classes) to this dir. But for your first tests - that’s enough.

 

'test' directory

In this directory we placed (and you’ll place) tests examples.

There are 2 sections of examples - using JUnit and using TestNG frameworks.

In each section you could find 2 tests - simple test with interaction with web driver functions directly from test, another - example of using PageObject pattern.

Also we add rule for junit and listener for testNG in which we implements screenshot taking method call on tests fail.

 

 

Conclusion.

Let’s again talk about main problems in first tests creation or tests on new project creation. Before you could use our plugin - there were many questions like how, where. You spent a lot of time on routine work of create simple basic classes, search for dependencies, configure environment.
Now you could create your project just by selecting it in IntelliJ IDEA ‘New Project’ menu. After click ‘Finish’ - you get ready to use and run project! Just in 5-10 seconds, instead of 1-2 hours.

If you have some problems with project setup, or you find some bugs, or you have ideas about how to make our project better - please contact us.

Together we will make our world much better!