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→
When running Selenium tests, in many situations one would like to wait to for some event to take place, before performing an action. For example, after clicking a button, one would need to wait for an element to be displayed until the test can use that element (the element being displayed is the event, using it is the action). Continue reading Waiting for UI events→
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→
When writing tests in TestNG, you will either mark your whole class with the @Test annotation (so that each public method that appears in your class will be considered a test method), or you will explicitly attach this annotation to every method you will run tests from. The latter approach allows for a bit of customization and differentiation among tests, by adding different values to the test attributes. Test attributes are @Test specific, and are to be specified right next to the @Test annotation. Some of the most common attributes are described below: Continue reading TestNG @Test attributes→
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→
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.
