Tag Archives: testng

Better Test Code Principles: #2 Don’t generate ALL your test data in @BeforeClass

A considerable amount of tests will need some test data to be generated previous to them running. Some people prefer to put all the data creation for all the tests in a class into the @BeforeClass method, some others prefer to keep the prerequisite data creation inside the tests themselves. Continue reading Better Test Code Principles: #2 Don’t generate ALL your test data in @BeforeClass

Advertisements

SoftAssert – don’t make your test fail on the first assertion failure

When you have more than one assertion in your test, you might want one of two things:

  1. Have your tests fail once the first assertion failure is encountered.
  2. Have all your assertions run, no matter if they have passed or failed. Of course, after they are run, if there are failures, you want the test to fail, and also show you where the issues were.

Continue reading SoftAssert – don’t make your test fail on the first assertion failure

Quick Tip: Running automated tests in parallel

The What

I have a bunch of tests that i would like to run faster, by making them execute in parallel. In my tests:

  1. I am not using a DataProvider and only want to make the same test run several times.
  2. I am using a DataProvider and want my test to run with the provided values from the provider, but in parallel.
  3. I am not using DataProviders, but my tests are ran by using the textng.xml file that specifies which tests to run (as per this article).

Continue reading Quick Tip: Running automated tests in parallel

DataProviders for TestNG tests

When you need to run the same test a number of times, by changing only a few variable values, instead of writing several identical tests, you can use the dataProvider functionality offered by TestNG. What you have to do is declare a dataProvider method that returns a list of lists of objects, pass it to the test method, change the test method’s signature to correspond to the types of objects found in each inner list and run the test. Continue reading DataProviders for TestNG tests

TestNG custom listeners: ITestListener


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.

Continue reading TestNG custom listeners: ITestListener

Running TestNG tests

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

TestNG @Test attributes


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