When running TestNG tests, one could want to perform some common actions – after each test has finished successfully, after each failed test, after each skipped test, or after all the tests have finished running, no matter their result. To apply such a common behavior to a group of tests, a custom listener can be created, that implements TestNG’s ITestListener interface. There are two types of methods to implement: a set of them are related to a single test’s run (onTestStart, onTestSuccess, onTestFailure, onTestSkipped, onTestFailedButWithinSuccessPercentage), the other to the whole suite’s run (onStart, onFinish). These methods, depending on their type, have a parameter passed to them: result, which is of type ITestResult – for the test run, and context, which is of type ITestContext, for the suite run. These types offer different information, for example: ITestResult can tell you when a test began to run, when it finished running, what status the test had (whether failed, passed), whereas ITestContext can tell you the list of all the passed tests, all the failed ones, and so on.
When writing tests that require the generation of random strings, a very useful class can come in handy, namely RandomStringUtils from the Apache Commons Langs utilities library. It can be used for generating string that contain only letters, only numbers, both, these and other characters. Continue reading Useful: generating random strings with RandomStringUtils
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