Running TestNG tests can be done in two ways: either directly from the IDE (by selecting the desired tests and choosing to ‘Run TestNG tests’) or from the command line. The latter option is very useful when trying to run only a selection of all the tests, that might spread across different classes or packages, or to run tests that belong to certain groups. To do this, you need to create some .xml files that will select the tests that need to run and/or exclude tests not to run, add a configuration in the Maven profile created for running the tests, and run the proper Maven command. Continue reading Running TestNG tests
Category Archives: tutorial
Common Selenium exceptions
Run tests on multiple browsers
Running tests on multiple browsers helps ensure that the behavior and look of your application is consistent for all your users. Selenium offers the possibility to use most common browsers to run your tests against. However, if your application needs to run also on mobile devices, from within their browsers (not from within native applications that is), there is an easy way to simulate the mobile devices your users would open your website on. You can use Chrome ‘s user agent capabilities. Also, you can run tests on your regular browsers by having some extensions active in the browser session (you might need some additional actions to be performed with the help of these extensions). Continue reading Run tests on multiple browsers
TestNG annotations
Tests written with the TestNG framework need to be annotated properly in order to be recognized as tests. A Java class will contain methods, that will either be the actual tests, or methods that perform some actions needed within a test. A class or a method that represent a test, will be annotated with the @Test annotation. A method or class that has this annotation needs to have the ‘public’ visibility. Having this in mind, if the @Test annotation is placed at the class level, all the methods within the class that are ‘public’ will be considered tests, and they will execute accordingly (as long as they don’t have one of the before/after annotations described lower in this post, for which there is a specific behavior). All the other methods, that are private or protected, will not be executed. Also, for this particular case, the public methods don’t even need to have the @TestNG annotation. However if you want to add attributes to some of the test methods, as described in this post , you will need to place the @Test attribute before each test method that will have the attributes. If you desire to place different attributes to test methods, you should put the @Test annotation next to each of these methods, otherwise, you can place the attributes within the class-level @Test annotation. Continue reading TestNG annotations
Creating the page objects
What is a page object
Simply put, a page object is an object that Selenium uses as a representation of an HTML element. Selenium tests will not interact with HTML code directly, but with objects that use selectors to refer to particular bits of the HTML code.
Defining page objects
You will need to create independent classes for declaring your page objects. Such a class should group together all the page objects that belong to the same page, or to the same module that is about to be tested. They should be grouped logically and naturally. The tests and page objects should not belong to the same Java class (they should be independent one of the other). This has a great number of advantages, amongst them: avoiding redundant code (having a page object in only one place), availability of a page object to every test class that needs it (every test class that needs an object will access it from the same location), changing of the selector will be done in only one place if the HTML code changes.
A recommended way of declaring a page object is presented here: Continue reading Creating the page objects
CSS Selectors

Identifying HTML elements in order to interact with them within you tests can be done by using CSS Selectors, which use pattern matching to easily find these elements. Below are the most used patterns to identify the elements on a page and examples of their usage: Continue reading CSS Selectors
XPATH selectors

To select HTML elements from your page, you can use XPath selectors, which are basically a set of expressions that will extract the nodes you require. The nodes are obtained by following a path in the HTML document, either downwards from a known node, or upwards (it searches for descendants or ancestors of a known element). To find elements using XPATH, find below what suits your search: Continue reading XPATH selectors
Setting up the Selenium bits
After the project is created, you need to setup the Selenium dependency, in order to use the library’s functionality. Make sure you always have the latest Selenium libraries available. The constant upgrade of the modern browsers might make some Selenium features unavailable or not working properly with older library versions.
Browser Releases
To see what browser releases are scheduled in the future, you can check out these links:
- For Chrome: http://googlechromereleases.blogspot.ro/
- For Firefox: https://wiki.mozilla.org/Releases
Browser Binaries
Create the Maven profile for running tests.
After the project has been created, you will need to decide how you want your automated tests to run. Keeping in mind that developers write unit tests, which by definition will validate of the code by itself, without interaction with other components, they are suitable to validate that the code commited satisfies the requirements in isolation. They should run fast, and not need interaction with browsers for example.
On the other hand, acceptance tests, which are the tests written by QAs should validate the code in the actual environment where it will reside, having contact with all the components around it. These tests validate that the code still acts properly when it runs in the system that it is built in. For that reason, these tests might take a long time to run, use browser instances, and might be rather fragile when it comes to succeeding. For example, Selenium tests are some of the most fragile, since, if you run tests in some sluggish environment, they might fail because of the slow responsiveness of the environment, pages not loading on time, and so on. Hence, running these tests for every project compilation phase is not feasible, as the build might never compile successfully. Continue reading Create the Maven profile for running tests.
Import the testing dependencies
The central and most essential part of a Maven project is its’ pom.xml file. Among other information (like the project’s defining artifactID and groupID), it stores the list of dependencies your project has and the plugins the project will use. Dependencies that are declared within the pom.xml file will be downloaded from the Maven repository configured for the project, into the project, as external libraries or dependencies. The default repository that is configured is the Maven central repository (http://search.maven.org/#search|ga|1|), and except for the situation where you explicitly configure a local repository, this is the place to look for the latest versions of the libraries you will import into your project. Continue reading Import the testing dependencies







