TestNG中英对照

本文翻译自TestNG官方文档：TestNG

Table of Contents

目录略

1 – Introduction

TestNG is a testing framework designed to simplify a broad range of testing needs, from unit testing (testing a class in isolation of the others) to integration testing (testing entire systems made of several classes, several packages and even several external frameworks, such as application servers).

TestNG是一个测试框架，设计来简化广泛的测试需求，从单元测试（隔离的情况下测试一个类）到集成测试（测试由几个类、包、甚至几个外部框架组成的整体系统，如应用服务器）

Writing a test is typically a three-step process:

编写测试通常三个步骤：

• Write the business logic of your test and insert TestNG annotations in your code.
• 编写测试业务逻辑，在代码中插入TestNG注解
• Add the information about your test (e.g. the class name, the groups you wish to run, etc…) in a testng.xml file or in build.xml.
• 在testng.xml文件或build.xml文件中添加关于测试信息（比如类名，想要运行的组等）
• Run TestNG.
• 运行TestNG

You can find a quick example on the Welcome page.

你可以在testng官方文档找到很多例子

The concepts used in this documentation are as follows:

文档中使用的概念如下：

• A suite is represented by one XML file. It can contain one or more tests and is defined by the <suite> tag.
• A test is represented by <test> and can contain one or more TestNG classes.
• A TestNG class is a Java class that contains at least one TestNG annotation. It is represented by the <class> tag and can contain one or more test methods.
• A test method is a Java method annotated by @Test in your source.

A TestNG test can be configured by @BeforeXXX and @AfterXXX annotations which allows to perform some Java logic before and after a certain point, these points being either of the items listed above.

The rest of this manual will explain the following:

• A list of all the annotations with a brief explanation. This will give you an idea of the various functionalities offered by TestNG but you will probably want to consult the section dedicated to each of these annotations to learn the details.
• A description of the testng.xml file, its syntax and what you can specify in it.
• A detailed list of the various features and how to use them with a combination of annotations and testng.xml.

2 – Annotations

Here is a quick overview of the annotations available in TestNG along with their attributes.

3 – testng.xml

You can invoke TestNG in several different ways:

• With a testng.xml file
• With ant
• From the command line

This section describes the format of testng.xml (you will find documentation on ant and the command line below).

The current DTD for testng.xml can be found on the main Web site:  testng-1.0.dtd (for your convenience, you might prefer to browse the HTML version).

Here is an example testng.xml file:

<!DOCTYPE suite SYSTEM "https://testng.org/testng-1.0.dtd" >
 
<suite name="Suite1" verbose="1" >
  <test name="Nopackage" >
    <classes>
       <class name="NoPackageTest" />
    </classes>
  </test>


  <test name="Regression1">
    <classes>
      <class name="test.sample.ParameterSample"/>
      <class name="test.sample.ParameterTest"/>
    </classes>
  </test>
</suite>

You can specify package names instead of class names:

<!DOCTYPE suite SYSTEM "https://testng.org/testng-1.0.dtd" >


<suite name="Suite1" verbose="1" >
  <test name="Regression1"   >
    <packages>
      <package name="test.sample" />
   </packages>
 </test>
</suite>

In this example, TestNG will look at all the classes in the package test.sample and will retain only classes that have TestNG annotations.

You can also specify groups and methods to be included and excluded:

<test name="Regression1">
  <groups>
    <run>
      <exclude name="brokenTests"  />
      <include name="checkinTests"  />
    </run>
  </groups>
 
  <classes>
    <class name="test.IndividualMethodsTest">
      <methods>
        <include name="testMethod" />
      </methods>
    </class>
  </classes>
</test>

You can also define new groups inside testng.xml and specify additional details in attributes, such as whether to run the tests in parallel, how many threads to use, whether you are running JUnit tests, etc…

By default, TestNG will run your tests in the order they are found in the XML file. If you want the classes and methods listed in this file to be run in an unpredictable order, set the preserve-order attribute to false

<test name="Regression1" preserve-order="false">
  <classes>


    <class name="test.Test1">
      <methods>
        <include name="m1" />
        <include name="m2" />
      </methods>
    </class>


    <class name="test.Test2" />


  </classes>
</test>

Please see the DTD for a complete list of the features, or read on.

4 – Running TestNG

TestNG can be invoked in different ways:

• Command line
• ant
• Eclipse
• IntelliJ’s IDEA

This section only explains how to invoke TestNG from the command line. Please click on one of the links above if you are interested in one of the other ways.

Assuming that you have TestNG in your class path, the simplest way to invoke TestNG is as follows:

java org.testng.TestNG testng1.xml [testng2.xml testng3.xml ...]

You need to specify at least one XML file describing the TestNG suite you are trying to run. Additionally, the following command-line switches are available:

This documentation can be obtained by invoking TestNG without any arguments.

You can also put the command line switches in a text file, say c:\command.txt, and tell TestNG to use that file to retrieve its parameters:

C:> more c:\command.txt
-d test-output testng.xml
C:> java org.testng.TestNG @c:\command.txt

Additionally, TestNG can be passed properties on the command line of the Java Virtual Machine, for example

java -Dtestng.test.classpath="c:/build;c:/java/classes;" org.testng.TestNG testng.xml

Here are the properties that TestNG understands:

Example:

The ant task and testng.xml allow you to launch TestNG with more parameters (methods to include, specifying parameters, etc…), so you should consider using the command line only when you are trying to learn about TestNG and you want to get up and running quickly.

Important: The command line flags that specify what tests should be run will be ignored if you also specify a testng.xml file, with the exception of -includedgroups and -excludedgroups, which will override all the group inclusions/exclusions found in testng.xml.

5 – Test methods, Test classes and Test groups

5.1 – Test methods

Test methods are annotated with @Test. Methods annotated with @Test that happen to return a value will be ignored, unless you set allow-return-values to true in your testng.xml:

<suite allow-return-values="true">


or


<test allow-return-values="true">

5.2 – Test groups

TestNG allows you to perform sophisticated groupings of test methods. Not only can you declare that methods belong to groups, but you can also specify groups that contain other groups. Then TestNG can be invoked and asked to include a certain set of groups (or regular expressions) while excluding another set.  This gives you maximum flexibility in how you partition your tests and doesn’t require you to recompile anything if you want to run two different sets of tests back to back.

Groups are specified in your testng.xml file and can be found either under the <test> or <suite> tag. Groups specified in the <suite> tag apply to all the <test> tags underneath. Note that groups are accumulative in these tags: if you specify group “a” in <suite> and “b” in <test>, then both “a” and “b” will be included.

For example, it is quite common to have at least two categories of tests

• Check-in tests.  These tests should be run before you submit new code.  They should typically be fast and just make sure no basic functionality was broken.
• Functional tests.  These tests should cover all the functionalities of your software and be run at least once a day, although ideally you would want to run them continuously.

Typically, check-in tests are a subset of functional tests.  TestNG allows you to specify this in a very intuitive way with test groups.  For example, you could structure your test by saying that your entire test class belongs to the “functest” group, and additionally that a couple of methods belong to the group “checkintest”:

public class Test1 {
  @Test(groups = { "functest", "checkintest" })
  public void testMethod1() {
  }


  @Test(groups = {"functest", "checkintest"} )
  public void testMethod2() {
  }


  @Test(groups = { "functest" })
  public void testMethod3() {
  }
}

Invoking TestNG with

<test name="Test1">
  <groups>
    <run>
      <include name="functest"/>
    </run>
  </groups>
  <classes>
    <class name="example1.Test1"/>
  </classes>
</test>

will run all the test methods in that classes, while invoking it with checkintest will only run testMethod1() and testMethod2().

Here is another example, using regular expressions this time.  Assume that some of your test methods should not be run on Linux, your test would look like:

@Test
public class Test1 {
  @Test(groups = { "windows.checkintest" })
  public void testWindowsOnly() {
  }


  @Test(groups = {"linux.checkintest"} )
  public void testLinuxOnly() {
  }


  @Test(groups = { "windows.functest" )
  public void testWindowsToo() {
  }
}

You could use the following testng.xml to launch only the Windows methods:

<test name="Test1">
  <groups>
    <run>
      <include name="windows.*"/>
    </run>
  </groups>


  <classes>
    <class name="example1.Test1"/>
  </classes>
</test>

Note: TestNG uses regular expressions, and not wildmats. Be aware of the difference (for example, “anything” is matched by “.*” — dot star — and not “*”).

Method groups

You can also exclude or include individual methods:

<test name="Test1">
  <classes>
    <class name="example1.Test1">
      <methods>
        <include name=".*enabledTestMethod.*"/>
        <exclude name=".*brokenTestMethod.*"/>
      </methods>
     </class>
  </classes>
</test>

This can come in handy to deactivate a single method without having to recompile anything, but I don’t recommend using this technique too much since it makes your testing framework likely to break if you start refactoring your Java code (the regular expressions used in the tags might not match your methods any more).

5.3 – Groups of groups

Groups can also include other groups. These groups are called “MetaGroups”.  For example, you might want to define a group “all” that includes “checkintest” and “functest”.  “functest” itself will contain the groups “windows” and “linux” while “checkintest will only contain “windows”.  Here is how you would define this in your property file:

<test name="Regression1">
  <groups>
    <define name="functest">
      <include name="windows"/>
      <include name="linux"/>
    </define>
 
    <define name="all">
      <include name="functest"/>
      <include name="checkintest"/>
    </define>
 
    <run>
      <include name="all"/>
    </run>
  </groups>
 
  <classes>
    <class name="test.sample.Test1"/>
  </classes>
</test>

5.4 – Exclusion groups

TestNG allows you to include groups as well as exclude them.

For example, it is quite usual to have tests that temporarily break because of a recent change, and you don’t have time to fix the breakage yet.  4 However, you do want to have clean runs of your functional tests, so you need to deactivate these tests but keep in mind they will need to be reactivated.

A simple way to solve this problem is to create a group called “broken” and make these test methods belong to it.  For example, in the above example, I know that testMethod2() is now broken so I want to disable it:

@Test(groups = {"checkintest", "broken"} )
public void testMethod2() {
}

All I need to do now is to exclude this group from the run:

<test name="Simple example">
  <groups>
    <run>
      <include name="checkintest"/>
      <exclude name="broken"/>
    </run>
  </groups>
 
  <classes>
    <class name="example1.Test1"/>
  </classes>
</test>

This way, I will get a clean test run while keeping track of what tests are broken and need to be fixed later.

Note:  you can also disable tests on an individual basis by using the “enabled” property available on both @Test and @Before/After annotations.

5.5 – Partial groups

You can define groups at the class level and then add groups at the method level:

@Test(groups = { "checkin-test" })
public class All {


  @Test(groups = { "func-test" )
  public void method1() { ... }


  public void method2() { ... }
}

In this class, method2() is part of the group “checkin-test”, which is defined at the class level, while method1() belongs to both “checkin-test” and “func-test”.

5.6 – Parameters

Test methods don’t have to be parameterless.  You can use an arbitrary number of parameters on each of your test method, and you instruct TestNG to pass you the correct parameters with the @Parameters annotation.

There are two ways to set these parameters:  with testng.xml or programmatically.

5.6.1 – Parameters from testng.xml

If you are using simple values for your parameters, you can specify them in your testng.xml:

@Parameters({ "first-name" })
@Test
public void testSingleString(String firstName) {
  System.out.println("Invoked testString " + firstName);
  assert "Cedric".equals(firstName);
}

In this code, we specify that the parameter firstName of your Java method should receive the value of the XML parameter called first-name.  This XML parameter is defined in testng.xml:

<suite name="My suite">
  <parameter name="first-name"  value="Cedric"/>
  <test name="Simple example">
  <-- ... -->

The same technique can be used for @Before/After and @Factory annotations:

@Parameters({ "datasource", "jdbcDriver" })
@BeforeMethod
public void beforeTest(String ds, String driver) {
  m_dataSource = ...;                              // look up the value of datasource
  m_jdbcDriver = driver;
}

This time, the two Java parameter ds and driver will receive the value given to the properties datasource and jdbc-driver respectively.

Parameters can be declared optional with the Optional annotation:

Parameters("db")
@Test
public void testNonExistentParameter(@Optional("mysql") String db) { ... }

If no parameter named “db” is found in your testng.xml file, your test method will receive the default value specified inside the @Optional annotation: “mysql”.

The @Parameters annotation can be placed at the following locations:

• On any method that already has a @Test, @Before/After or @Factory annotation.
• On at most one constructor of your test class.  In this case, TestNG will invoke this particular constructor with the parameters initialized to the values specified in testng.xml whenever it needs to instantiate your test class.  This feature can be used to initialize fields inside your classes to values that will then be used by your test methods.

Notes:

• The XML parameters are mapped to the Java parameters in the same order as they are found in the annotation, and TestNG will issue an error if the numbers don’t match.
• Parameters are scoped. In testng.xml, you can declare them either under a <suite> tag or under <test>. If two parameters have the same name, it’s the one defined in <test> that has precedence. This is convenient if you need to specify a parameter applicable to all your tests and override its value only for certain tests.

 

5.6.2 – Parameters with DataProviders

Specifying parameters in testng.xml might not be sufficient if you need to pass complex parameters, or parameters that need to be created from Java (complex objects, objects read from a property file or a database, etc…). In this case, you can use a Data Provider to supply the values you need to test.  A Data Provider is a method on your class that returns an array of array of objects.  This method is annotated with @DataProvider:

//This method will provide data to any test method that declares that its Data Provider
//is named "test1"
@DataProvider(name = "test1")
public Object[][] createData1() {
 return new Object[][] {
   { "Cedric", new Integer(36) },
   { "Anne", new Integer(37)},
 };
}


//This test method declares that its data should be supplied by the Data Provider
//named "test1"
@Test(dataProvider = "test1")
public void verifyData1(String n1, Integer n2) {
 System.out.println(n1 + " " + n2);
}

will print

Cedric 36
Anne 37

A @Test method specifies its Data Provider with the dataProvider attribute.  This name must correspond to a method on the same class annotated with @DataProvider(name="...") with a matching name.

By default, the data provider will be looked for in the current test class or one of its base classes. If you want to put your data provider in a different class, it needs to be a static method or a class with a non-arg constructor, and you specify the class where it can be found in the dataProviderClass attribute:

public class StaticProvider {
  @DataProvider(name = "create")
  public static Object[][] createData() {
    return new Object[][] {
      new Object[] { new Integer(42) }
    };
  }
}


public class MyTest {
  @Test(dataProvider = "create", dataProviderClass = StaticProvider.class)
  public void test(Integer n) {
    // ...
  }
}

The data provider supports injection too. TestNG will use the test context for the injection. The Data Provider method can return one of the following types:

• An array of array of objects (Object[][]) where the first dimension’s size is the number of times the test method will be invoked and the second dimension size contains an array of objects that must be compatible with the parameter types of the test method. This is the case illustrated by the example above.
• An Iterator<Object[]>. The only difference with Object[][] is that an Iterator lets you create your test data lazily. TestNG will invoke the iterator and then the test method with the parameters returned by this iterator one by one. This is particularly useful if you have a lot of parameter sets to pass to the method and you don’t want to create all of them upfront.
  • An array of objects (Object[]). This is similar to Iterator<Object[]> but causes the test method to be invoked once for each element of the source array.
  • An Iterator<Object>>. Lazy alternative of Object[]. Causes the test method to be invoked once for each element of the iterator.

It must be said that return type is not limited to Object only thus MyCustomData[][] or Iterator<Supplier> are also possible. The only limitation is that in case of iterator its parameter type can’t be explicitly parametrized itself. Here is an example of this feature:

@DataProvider(name = "test1")
public Iterator<Object[]> createData() {
  return new MyIterator(DATA);
}

Using MyCustomData[] as a return type

@DataProvider(name = "test1")
public MyCustomData[] createData() {
  return new MyCustomData[]{ new MyCustomData() };
}

Or its lazy option with Iterator<MyCustomData>

@DataProvider(name = "test1")
public Iterator<MyCustomData> createData() {
  return Arrays.asList(new MyCustomData()).iterator();
}

Parameter type (Stream) of Iterator can’t be explicitly parametrized

@DataProvider(name = "test1")
public Iterator<Stream> createData() {
  return Arrays.asList(Stream.of("a", "b", "c")).iterator();
}

If you declare your @DataProvider as taking a java.lang.reflect.Method as first parameter, TestNG will pass the current test method for this first parameter. This is particularly useful when several test methods use the same @DataProvider and you want it to return different values depending on which test method it is supplying data for.

For example, the following code prints the name of the test method inside its @DataProvider:

@DataProvider(name = "dp")
public Object[][] createData(Method m) {
  System.out.println(m.getName());  // print test method name
  return new Object[][] { new Object[] { "Cedric" }};
}


@Test(dataProvider = "dp")
public void test1(String s) {
}


@Test(dataProvider = "dp")
public void test2(String s) {
}

and will therefore display:

test1
test2

Data providers can run in parallel with the attribute parallel:

@DataProvider(parallel = true)
// ...

Parallel data providers running from an XML file share the same pool of threads, which has a size of 10 by default. You can modify this value in the <suite> tag of your XML file:

<suite name="Suite1" data-provider-thread-count="20" >
...

If you want to run a few specific data providers in a different thread pool, you need to run them from a different XML file.

5.6.3 – Parameters in reports

Parameters used to invoke your test methods are shown in the HTML reports generated by TestNG. Here is an example:

5.7 – Dependencies

Sometimes, you need your test methods to be invoked in a certain order.  Here are a few examples:

• To make sure a certain number of test methods have completed and succeeded before running more test methods.
• To initialize your tests while wanting this initialization methods to be test methods as well (methods tagged with @Before/After will not be part of the final report).

TestNG allows you to specify dependencies either with annotations or in XML.

5.7.1 – Dependencies with annotations

You can use the attributes dependsOnMethods or dependsOnGroups, found on the @Test annotation.

There are two kinds of dependencies:

• Hard dependencies. All the methods you depend on must have run and succeeded for you to run. If at least one failure occurred in your dependencies, you will not be invoked and marked as a SKIP in the report.
• Soft dependencies. You will always be run after the methods you depend on, even if some of them have failed. This is useful when you just want to make sure that your test methods are run in a certain order but their success doesn’t really depend on the success of others. A soft dependency is obtained by adding "alwaysRun=true" in your @Test annotation.

Here is an example of a hard dependency:

In this example, method1() is declared as depending on method serverStartedOk(), which guarantees that serverStartedOk() will always be invoked first.

You can also have methods that depend on entire groups:

In this example, method1() is declared as depending on any group matching the regular expression “init.*”, which guarantees that the methods serverStartedOk() and initEnvironment() will always be invoked before method1().

Note:  as stated before, the order of invocation for methods that belong in the same group is not guaranteed to be the same across test runs.

If a method depended upon fails and you have a hard dependency on it (alwaysRun=false, which is the default), the methods that depend on it are not marked as FAIL but as SKIP.  Skipped methods will be reported as such in the final report (in a color that is neither red nor green in HTML), which is important since skipped methods are not necessarily failures.

Both dependsOnGroups and dependsOnMethods accept regular expressions as parameters.  For dependsOnMethods, if you are depending on a method which happens to have several overloaded versions, all the overloaded methods will be invoked.  If you only want to invoke one of the overloaded methods, you should use dependsOnGroups.

For a more advanced example of dependent methods, please refer to this article, which uses inheritance to provide an elegant solution to the problem of multiple dependencies.

By default, dependent methods are grouped by class. For example, if method b() depends on method a() and you have several instances of the class that contains these methods (because of a factory of a data provider), then the invocation order will be as follows:

TestNG will not run b() until all the instances have invoked their a() method.

This behavior might not be desirable in certain scenarios, such as for example testing a sign in and sign out of a web browser for various countries. In such a case, you would like the following ordering:

For this ordering, you can use the XML attribute group-by-instances. This attribute is valid either on <suite> or <test>:

5.7.2 – Dependencies in XML

Alternatively, you can specify your group dependencies in the testng.xml file. You use the <dependencies> tag to achieve this:

The <depends-on> attribute contains a space-separated list of groups.

5.8 – Factories

Factories allow you to create tests dynamically. For example, imagine you want to create a test method that will access a page on a Web site several times, and you want to invoke it with different values:

This can become quickly impossible to manage, so instead, you should use a factory:

and the new test class is now:

Your testng.xml only needs to reference the class that contains the factory method, since the test instances themselves will be created at runtime:

Or, if building a test suite instance programatically, you can add the factory in the same manner as for tests:

The factory method can receive parameters just like @Test and @Before/After and it must return Object[].  The objects returned can be of any class (not necessarily the same class as the factory class) and they don’t even need to contain TestNG annotations (in which case they will be ignored by TestNG).

Factories can also be used with data providers, and you can leverage this functionality by putting the @Factory annotation either on a regular method or on a constructor. Here is an example of a constructor factory:

The example will make TestNG create two test classes, on with the constructor invoked with the value 41 and the other with 42.

5.9 – Class level annotations

The @Test annotation can be put on a class instead of a test method:

The effect of a class level @Test annotation is to make all the public methods of this class to become test methods even if they are not annotated. You can still repeat the @Test annotation on a method if you want to add certain attributes.

For example:

will make both test1() and test2() test methods but on top of that, test2() now belongs to the group “g1”.

5.10 – Ignoring tests

TestNG lets you ignore all the @Test methods :

• In a class (or)
• In a particular package (or)
• In a package and all of its child packages

using the new annotation @Ignore.

When used at the method level @Ignore annotation is functionally equivalent to @Test(enabled=false). Here’s a sample that shows how to ignore all tests within a class.

The @Ignore annotation has a higher priority than individual @Test method annotations. When @Ignore is placed on a class, all the tests in that class will be disabled.

To ignore all tests in a particular package, you just need to create package-info.java and add the @Ignore annotation to it. Here’s a sample :

This causes all the @Test methods to be ignored in the package com.testng.master and all of its sub-packages.

5.11 – Parallelism and time-outs

You can instruct TestNG to run your tests in separate threads in various ways.

5.11.1 – Parallel suites

This is useful if you are running several suite files (e.g. “java org.testng.TestNG testng1.xml testng2.xml") and you want each of these suites to be run in a separate thread. You can use the following command line flag to specify the size of a thread pool:

The corresponding ant task name is suitethreadpoolsize.

5.11.2 – Parallel tests, classes and methods

The parallel attribute on the <suite> tag can take one of following values:

• • parallel="methods": TestNG will run all your test methods in separate threads. Dependent methods will also run in separate threads but they will respect the order that you specified.

• • parallel="tests": TestNG will run all the methods in the same <test> tag in the same thread, but each <test> tag will be in a separate thread. This allows you to group all your classes that are not thread safe in the same <test> and guarantee they will all run in the same thread while taking advantage of TestNG using as many threads as possible to run your tests.

• • parallel="classes": TestNG will run all the methods in the same class in the same thread, but each class will be run in a separate thread.

• parallel="instances": TestNG will run all the methods in the same instance in the same thread, but two methods on two different instances will be running in different threads.

Additionally, the attribute thread-count allows you to specify how many threads should be allocated for this execution.

Note: the @Test attribute timeOut works in both parallel and non-parallel mode.

You can also specify that a @Test method should be invoked from different threads. You can use the attribute threadPoolSize to achieve this result:

In this example, the function testServer will be invoked ten times from three different threads. Additionally, a time-out of ten seconds guarantees that none of the threads will block on this thread forever.

5.12 – Rerunning failed tests

Every time tests fail in a suite, TestNG creates a file called testng-failed.xml in the output directory. This XML file contains the necessary information to rerun only these methods that failed, allowing you to quickly reproduce the failures without having to run the entirety of your tests.  Therefore, a typical session would look like this:

Note that testng-failed.xml will contain all the necessary dependent methods so that you are guaranteed to run the methods that failed without any SKIP failures.

Sometimes, you might want TestNG to automatically retry a test whenever it fails. In those situations, you can use a retry analyzer. When you bind a retry analyzer to a test, TestNG automatically invokes the retry analyzer to determine if TestNG can retry a test case again in an attempt to see if the test that just fails now passes. Here is how you use a retry analyzer:

1. Build an implementation of the interface org.testng.IRetryAnalyzer
2. Bind this implementation to the @Test annotation for e.g., @Test(retryAnalyzer = LocalRetry.class)

Following is a sample implementation of the retry analyzer that retries a test for a maximum of three times.

5.13 – JUnit tests

TestNG can run JUnit 3 and JUnit 4 tests.  All you need to do is put the JUnit jar file on the classpath, specify your JUnit test classes in the testng.classNames property and set the testng.junit property to true:

The behavior of TestNG in this case is similar to JUnit depending on the JUnit version found on the class path:

• JUnit 3:
  • All methods starting with test* in your classes will be run
  • If there is a method setUp() on your test class, it will be invoked before every test method
  • If there is a method tearDown() on your test class, it will be invoked before after every test method
  • If your test class contains a method suite(), all the tests returned by this method will be invoked
• JUnit 4:
  • TestNG will use the org.junit.runner.JUnitCore runner to run your tests

5.14 – Running TestNG programmatically

You can invoke TestNG from your own programs very easily:

This example creates a TestNG object and runs the test class Run2. It also adds a TestListener. You can either use the adapter class org.testng.TestListenerAdapter or implement org.testng.ITestListener yourself. This interface contains various callback methods that let you keep track of when a test starts, succeeds, fails, etc…

Similarly, you can invoke TestNG on a testng.xml file or you can create a virtual testng.xml file yourself. In order to do this, you can use the classes found the package org.testng.xml: XmlClass, XmlTest, etc… Each of these classes correspond to their XML tag counterpart.

For example, suppose you want to create the following virtual file:

You would use the following code:

And then you can pass this XmlSuite to TestNG:

Please see the JavaDocs for the entire API.

5.15 – BeanShell and advanced group selection

If the <include> and <exclude> tags in testng.xml are not enough for your needs, you can use a BeanShell expression to decide whether a certain test method should be included in a test run or not. You specify this expression just under the <test> tag:

When a <script> tag is found in testng.xml, TestNG will ignore subsequent <include> and <exclude> of groups and methods in the current <test> tag:  your BeanShell expression will be the only way to decide whether a test method is included or not.

Here are additional information on the BeanShell script:

• It must return a boolean value.  Except for this constraint, any valid BeanShell code is allowed (for example, you might want to return true during week days and false during weekends, which would allow you to run tests differently depending on the date).
• TestNG defines the following variables for your convenience:
  java.lang.reflect.Method method:  the current test method.
  org.testng.ITestNGMethod testngMethod:  the description of the current test method.
  java.util.Map<String, String> groups:  a map of the groups the current test method belongs to.
• You might want to surround your expression with a CDATA declaration (as shown above) to avoid tedious quoting of reserved XML characters).

5.16 – Annotation Transformers

TestNG allows you to modify the content of all the annotations at runtime. This is especially useful if the annotations in the source code are right most of the time, but there are a few situations where you’d like to override their value.

In order to achieve this, you need to use an Annotation Transformer.

An Annotation Transformer is a class that implements the following interface:

Like all the other TestNG listeners, you can specify this class either on the command line or with ant:

or programmatically:

When the method transform() is invoked, you can call any of the setters on the ITest test parameter to alter its value before TestNG proceeds further.

For example, here is how you would override the attribute invocationCount but only on the test method invoke() of one of your test classes:

IAnnotationTransformer only lets you modify a @Test annotation. If you need to modify another TestNG annotation (a configuration annotation, @Factory or @DataProvider), use an IAnnotationTransformer2.

5.17 – Method Interceptors

Once TestNG has calculated in what order the test methods will be invoked, these methods are split in two groups:

• Methods run sequentially. These are all the test methods that have dependencies or dependents. These methods will be run in a specific order.
• Methods run in no particular order. These are all the methods that don’t belong in the first category. The order in which these test methods are run is random and can vary from one run to the next (although by default, TestNG will try to group test methods by class).

In order to give you more control on the methods that belong to the second category, TestNG defines the following interface:

The list of methods passed in parameters are all the methods that can be run in any order. Your intercept method is expected to return a similar list of IMethodInstance, which can be either of the following:

• The same list you received in parameter but in a different order.
• A smaller list of IMethodInstance objects.
• A bigger list of IMethodInstance objects.

Once you have defined your interceptor, you pass it to TestNG as a listener. For example:

For the equivalent ant syntax, see the listeners attribute in the ant documentation.

For example, here is a Method Interceptor that will reorder the methods so that test methods that belong to the group “fast” are always run first:

5.18 – TestNG Listeners

There are several interfaces that allow you to modify TestNG’s behavior. These interfaces are broadly called “TestNG Listeners”. Here are a few listeners:

• IAnnotationTransformer (doc, javadoc)
• IAnnotationTransformer2 (doc, javadoc)
• IHookable (doc, javadoc)
• IInvokedMethodListener (doc, javadoc)
• IMethodInterceptor (doc, javadoc)
• IReporter (doc, javadoc)
• ISuiteListener (doc, javadoc)
• ITestListener (doc, javadoc)

When you implement one of these interfaces, you can let TestNG know about it with either of the following ways:

• Using -listener on the command line.
• Using <listeners> with ant.
• Using <listeners> in your testng.xml file.
• Using the @Listeners annotation on any of your test classes.
• Using ServiceLoader.

5.18.1 – Specifying listeners with testng.xml or in Java

Here is how you can define listeners in your testng.xml file:

Or if you prefer to define these listeners in Java:

The @Listeners annotation can contain any class that extends org.testng.ITestNGListener except IAnnotationTransformer and IAnnotationTransformer2. The reason is that these listeners need to be known very early in the process so that TestNG can use them to rewrite your annotations, therefore you need to specify these listeners in your testng.xml file.

Note that the @Listeners annotation will apply to your entire suite file, just as if you had specified it in a testng.xml file. If you want to restrict its scope (for example, only running on the current class), the code in your listener could first check the test method that’s about to run and decide what to do then. Here’s how it can be done.

1. First define a new custom annotation that can be used to specify this restriction:

   @Retention(RetentionPolicy.RUNTIME)

   @Target ({ElementType.TYPE})

   public @interface DisableListener {}

2. Add an edit check as below within your regular listeners:

   public void beforeInvocation(IInvokedMethod iInvokedMethod, ITestResult iTestResult) {

   ConstructorOrMethod consOrMethod =iInvokedMethod.getTestMethod().getConstructorOrMethod();

   DisableListener disable = consOrMethod.getMethod().getDeclaringClass().getAnnotation(DisableListener.class);

   if (disable != null) {

   return;

   }

   // else resume your normal operations

   }

3. Annotate test classes wherein the listener is not to be invoked:

   @DisableListener

   @Listeners({ com.example.MyListener.class, com.example.MyMethodInterceptor.class })

   public class MyTest {

   // ...

   }

5.18.2 – Specifying listeners with ServiceLoader

Finally, the JDK offers a very elegant mechanism to specify implementations of interfaces on the class path via the ServiceLoader class.

With ServiceLoader, all you need to do is create a jar file that contains your listener(s) and a few configuration files, put that jar file on the classpath when you run TestNG and TestNG will automatically find them.

Here is a concrete example of how it works.

Let’s start by creating a listener (any TestNG listener should work):

Compile this file, then create a file at the location META-INF/services/org.testng.ITestNGListener, which will name the implementation(s) you want for this interface.

You should end up with the following directory structure, with only two files:

Create a jar of this directory:

Next, put this jar file on your classpath when you invoke TestNG:

This mechanism allows you to apply the same set of listeners to an entire organization just by adding a jar file to the classpath, instead of asking every single developer to remember to specify these listeners in their testng.xml file.

5.19 – Dependency injection

TestNG supports two different kinds of dependency injection: native (performed by TestNG itself) and external (performed by a dependency injection framework such as Guice).

5.19.1 – Native dependency injection

TestNG lets you declare additional parameters in your methods. When this happens, TestNG will automatically fill these parameters with the right value. Dependency injection can be used in the following places:

• Any @Before method or @Test method can declare a parameter of type ITestContext.
• Any @AfterMethod method can declare a parameter of type ITestResult, which will reflect the result of the test method that was just run.
• Any @Before and @After methods (except @BeforeSuite and @AfterSuite) can declare a parameter of type XmlTest, which contain the current <test> tag.
• Any @BeforeMethod (and @AfterMethod) can declare a parameter of type java.lang.reflect.Method. This parameter will receive the test method that will be called once this @BeforeMethod finishes (or after the method as run for @AfterMethod).
• Any @BeforeMethod can declare a parameter of type Object[]. This parameter will receive the list of parameters that are about to be fed to the upcoming test method, which could be either injected by TestNG, such as java.lang.reflect.Method or come from a @DataProvider.
• Any @DataProvider can declare a parameter of type ITestContext or java.lang.reflect.Method. The latter parameter will receive the test method that is about to be invoked.

You can turn off injection with the @NoInjection annotation:

The below table summarises the parameter types that can be natively injected for the various TestNG annotations:

5.19.2 – Guice dependency injection

If you use Guice, TestNG gives you an easy way to inject your test objects with a Guice module:

In this example, GuiceExampleModule is expected to bind the interface ISingleton to some concrete class:

If you need more flexibility in specifying which modules should be used to instantiate your test classes, you can specify a module factory:

The module factory needs to implement the interface IModuleFactory:

Your factory will be passed an instance of the test context and the test class that TestNG needs to instantiate. Your createModule method should return a Guice Module that will know how to instantiate this test class. You can use the test context to find out more information about your environment, such as parameters specified in testng.xml, etc… You will get even more flexibility and Guice power with parent-module and guice-stage suite parameters. guice-stage allow you to chose the Stage used to create the parent injector. The default one is DEVELOPMENT. Other allowed values are PRODUCTION and TOOL. Here is how you can define parent-module in your test.xml file:

TestNG will create this module only once for given suite. Will also use this module for obtaining instances of test specific Guice modules and module factories, then will create child injector for each test class. With such approach you can declare all common bindings in parent-module also you can inject binding declared in parent-module in module and module factory. Here is an example of this functionality:

As you see ParentModule declares binding for MyService and MyContext classes. Then MyContext is injected using constructor injection into TestModule class, which also declare binding for MySession. Then parent-module in test XML file is set to ParentModule class, this enables injection in TestModule. Later in TestClass you see two injections: * MyService – binding taken from ParentModule * MySession – binding taken from TestModule This configuration ensures you that all tests in this suite will be run with same session instance, the MyContextImpl object is only created once per suite, this give you possibility to configure common environment state for all tests in suite.

5.20 – Listening to method invocations

The listener IInvokedMethodListener allows you to be notified whenever TestNG is about to invoke a test (annotated with @Test) or configuration (annotated with any of the @Before or @After annotation) method. You need to implement the following interface:

and declare it as a listener, as explained in the section about TestNG listeners.

5.21 – Overriding test methods

TestNG allows you to override and possibly skip the invocation of test methods. One example of where this is useful is if you need to your test methods with a specific security manager. You achieve this by providing a listener that implements IHookable.

Here is an example with JAAS:

5.22 – Altering suites (or) tests

Sometimes you may need to just want to alter a suite (or) a test tag in a suite xml in runtime without having to change the contents of a suite file.

A classic example for this would be to try and leverage your existing suite file and try using it for simulating a load test on your “Application under test”. At the minimum you would end up duplicating the contents of your <test> tag multiple times and create a new suite xml file and work with. But this doesn’t seem to scale a lot.

TestNG allows you to alter a suite (or) a test tag in your suite xml file at runtime via listeners. You achieve this by providing a listener that implements IAlterSuiteListener. Please refer to Listeners section to learn about listeners.

Here is an example that shows how the suite name is getting altered in runtime:

This listener can only be added with either of the following ways:

• Through the <listeners> tag in the suite xml file.
• Through a Service Loader

This listener cannot be added to execution using the @Listeners annotation.

6 – Test results

6.1 – Success, failure and assert

A test is considered successful if it completed without throwing any exception or if  it threw an exception that was expected (see the documentation for the expectedExceptions attribute found on the @Test annotation).

Your test methods will typically be made of calls that can throw an exception, or of various assertions (using the Java “assert” keyword).  An “assert” failing will trigger an AssertionErrorException, which in turn will mark the method as failed (remember to use -ea on the JVM if you are not seeing the assertion errors).

Here is an example test method:

TestNG also include JUnit’s Assert class, which lets you perform assertions on complex objects:

Note that the above code use a static import in order to be able to use the assertEquals method without having to prefix it by its class.

6.2 – Logging and results

The results of the test run are created in a file called index.html in the directory specified when launching SuiteRunner.  This file points to various other HTML and text files that contain the result of the entire test run.

It’s very easy to generate your own reports with TestNG with Listeners and Reporters:

• Listeners implement the interface org.testng.ITestListener and are notified in real time of when a test starts, passes, fails, etc…
• Reporters implement the interface org.testng.IReporter and are notified when all the suites have been run by TestNG. The IReporter instance receives a list of objects that describe the entire test run.

For example, if you want to generate a PDF report of your test run, you don’t need to be notified in real time of the test run so you should probably use an IReporter. If you’d like to write a real-time reporting of your tests, such as a GUI with a progress bar or a text reporter displaying dots (“.”) as each test is invoked (as is explained below), ITestListener is your best choice.

6.2.1 – Logging Listeners

Here is a listener that displays a “.” for each passed test, a “F” for each failure and a “S” for each skip:

In this example, I chose to extend TestListenerAdapter, which implements ITestListener with empty methods, so I don’t have to override other methods from the interface that I have no interest in. You can implement the interface directly if you prefer.

Here is how I invoke TestNG to use this new listener:

and the output:

Note that when you use -listener, TestNG will automatically determine the type of listener you want to use.

6.2.2 – Logging Reporters

The org.testng.IReporter interface only has one method:

This method will be invoked by TestNG when all the suites have been run and you can inspect its parameters to access all the information on the run that was just completed.

6.2.3 – JUnitReports

TestNG contains a listener that takes the TestNG results and outputs an XML file that can then be fed to JUnitReport. Here is an example, and the ant task to create this report:

Note:  a current incompatibility between the JDK 1.5 and JUnitReports prevents the frame version from working, so you need to specify “noframes” to get this to work for now.

6.2.4 – Reporter API

If you need to log messages that should appear in the generated HTML reports, you can use the class org.testng.Reporter:

    Reporter.log(“M3 WAS CALLED”);

6.2.5 – XML Reports

TestNG offers an XML reporter capturing TestNG specific information that is not available in JUnit reports. This is particularly useful when the user’s test environment needs to consume XML results with TestNG-specific data that the JUnit format can’t provide. This reporter can be injected into TestNG via the command line with -reporter.

Here’s a sample usage: -reporter org.testng.reporters.XMLReporter:generateTestResultAttributes=true,generateGroupsAttribute=true.

The full set of options that can be passed is detailed in the below table. Make sure to use :

• : – to separate the reporter name from its properties
• = – to separate key/value pairs for properties
• , – to separate multiple key/value pairs

Below is a sample of the output of such a reporter:

This reporter is injected along with the other default listeners so you can get this type of output by default. The listener provides some properties that can tweak the reporter to fit your needs. The following table contains a list of these properties with a short explanation:

   1 - will generate all the results in one file.
   2 - each suite is generated in a separate XML file that is linked to the main file.
   3 - same as 2 plus separate files for test-cases that are referenced from the suite files.

   0 - no stacktrace (just Exception class and message).
   1 - a short version of the stack trace keeping just a few lines from the top
   2 - the complete stacktrace with all the inner exceptions
   3 - both short and long stacktrace

In order to configure this reporter you can use the -reporter option in the command line or the Ant task with the nested <reporter> element. For each of these you must specify the class org.testng.reporters.XMLReporter. Please note that you cannot configure the built-in reporter because this one will only use default settings. If you need just the XML report with custom settings you will have to add it manually with one of the two methods and disable the default listeners.

6.2.6 – TestNG Exit Codes

When TestNG completes execution, it exits with a return code.
This return code can be inspected to get an idea on the nature of failures (if there were any).
The following table summarises the different exit codes that TestNG currently uses.

7 – YAML

TestNG supports YAML as an alternate way of specifying your suite file. For example, the following XML file:

and here is its YAML version:

Here is TestNG’s own suite file, and its YAML counterpart.

You might find the YAML file format easier to read and to maintain. YAML files are also recognized by the TestNG Eclipse plug-in. You can find more information about YAML and TestNG in this blog post.

Note:
TestNG by default does not bring in the YAML related library into your classpath. So depending upon your build system (Gradle/Maven) you need to add an explicit reference to YAML library in your build file.
For e.g, If you were using Maven, you would need to add a dependency as below into your pom.xml file:

Or if you were using Gradle, you would add a dependency as below into your build.gradle file:

8 – Dry Run for your tests

When launched in dry run mode, TestNG will display a list of the test methods that would be invoked but without actually calling them.

You can enable dry run mode for TestNG by passing the JVM argument -Dtestng.mode.dryrun=true

9 – JVM Arguments in TestNG

Back to my home page.

Or check out some of my other projects:

• EJBGen:  an EJB tag generator.
• TestNG:  A testing framework using annotations, test groups and method parameters.
• Doclipse:  a JavaDoc tag Eclipse plug-in.
• J15:  an Eclipse plug-in to help you migrate your code to the new JDK 1.5 constructs.
• SGen:  a replacement for XDoclet with an easy plug-in architecture.
• Canvas:  a template generator based on the Groovy language.