How to use merge method of org.testng.collections.Lists class

I use a similar setup, except I am using Dropbox for my repository (just two developers). Just follow these steps, with the m2eclipse (update site: http://m2eclipse.sonatype.org/sites/m2e) and the MercurialEclipse (update site: http://cbes.javaforge.com/update) plugin you can do all in eclipse.

Create a maven project:

File -> New -> Other -> Maven project

In Project explorer right click on the new created maven project

Team -> Share Project... -> Mercurial -> (leave the folder as it is) Finish

Then create an .hgignore file in the project root:

In Project explorer right click on the new created maven project

New -> File -> File Name: .hgignore and Finish

.hgignore:

syntax: regexp
target      # maven output
\.classpath # eclipse
\.project   # eclipse
\.settings  # eclipse
test-output # eclipse junit/testng plugin output

Then you can make your first commit, but beware, hg does not store empty folders in it's repository, so to keep the maven folder structure with no source code in it you have to put a (empty) file in each empty folder, for a simple maven project without any sources it would be in the folders:

• myproject/src/main/java
• myproject/src/main/resources
• myproject/src/test/java
• myproject/src/test/resources

For example I put a file with the name .empty in it with the content "this is a placeholder file, remove if other files are in this folder"

If some of this folders are missing your colleagues would see errors in eclipse if they import your project.

First commit:

In Project explorer right click on the new created maven project

Team -> Commit... -> Select all and enter a commit message -> Finish

Now you can clone it to bitbucket (I don't have experience with bitbucket).

Tell your colleagues to install the two eclipse plugins and then they can get the repo via

File -> New -> Other -> Check out Maven Project from SCM -> enter url to your repo -> Finish

And then you are good to go.

Spock does have listeners. Unfortunately the official documentation, which is otherwise excellent, has "TODO" under Writing Custom Extensions: http://spockframework.github.io/spock/docs/1.0/extensions.html.

Update: The official docs have been updated to include helpful information about custom extensions: http://spockframework.org/spock/docs/1.1/extensions.html. See those for more details.

There are two ways: Annotation-based and Global.

Annotation-based

Three pieces here: the annotation, the extension, and the listener.

The annotation:

    import java.lang.annotation.*
    import org.spockframework.runtime.extension.ExtensionAnnotation

    @Retention(RetentionPolicy.RUNTIME)
    @Target([ElementType.TYPE, ElementType.METHOD])
    @ExtensionAnnotation(ListenForErrorsExtension)
    @interface ListenForErrors {}

The extension (Updated):

    import org.spockframework.runtime.extension.AbstractAnnotationDrivenExtension
    import org.spockframework.runtime.model.SpecInfo

    class ListenForErrorsExtension extends AbstractAnnotationDrivenExtension<ListenForErrors> {
        void visitSpec(SpecInfo spec) {
            spec.addListener(new ListenForErrorsListener())
        }

       @Override
       void visitSpecAnnotation(ListenForErrors annotation, SpecInfo spec){
        println "do whatever you need here if you do. This method will throw an error unless you override it"
    }
    }

The listener:

    import org.spockframework.runtime.AbstractRunListener
    import org.spockframework.runtime.model.ErrorInfo

    class ListenForErrorsListener extends AbstractRunListener {
        void error(ErrorInfo error) {
            println "Test failed: ${error.method.name}"
            // Do other handling here
        }
    }

You can then use your new annotation on a Spec class or method:

    @ListenForErrors
    class MySpec extends Specification {
        ...
    }

Global

This also has three pieces: the extension, the listener, and the registration.

    class ListenForErrorsExtension implements IGlobalExtension {
        void visitSpec(SpecInfo specInfo) {
            specInfo.addListener(new ListenForErrorsListener())
        }
    }

You can use the same ListenForErrorsListener class as above.

To register the extension, create a file named org.spockframework.runtime.extension.IGlobalExtension in the META-INF/services directory. If using Gradle/Maven, this will be under src/test/resources. This file should contain only the fully qualified class name of your global extension, for example:

com.example.tests.ListenForErrorsExtension

References

For examples, see the Spock built-in extensions here: https://github.com/spockframework/spock/tree/groovy-1.8/spock-core/src/main/java/spock/lang https://github.com/spockframework/spock/tree/groovy-1.8/spock-core/src/main/java/org/spockframework/runtime/extension/builtin

You can stub a static void method like this:

PowerMockito.doNothing().when(StaticResource.class, "getResource", anyString());

Although I'm not sure why you would bother, because when you call mockStatic(StaticResource.class) all static methods in StaticResource are by default stubbed

More useful, you can capture the value passed to StaticResource.getResource() like this:

ArgumentCaptor<String> captor = ArgumentCaptor.forClass(String.class);
PowerMockito.doNothing().when(
               StaticResource.class, "getResource", captor.capture());

Then you can evaluate the String that was passed to StaticResource.getResource like this:

String resourceName = captor.getValue();

Instead of

public class MyTestNGTest {
    @Inject private Provider<Thing> thingProvider;

    @Test
    public void test1() {
        Thing thing = thingProvider.get();

In TestNG you can used

public class MyTestNGTest {
    @Inject 
    private Thing thingInjected;
    private Thing thing;

    @BeforeTest
    public void doBeforeTest() {
        thing = thingInjected.clone();
    }

Or just call thingProvider.get() in doBeforeTest(), it's better in you have a lot of @ Test

public class MyTestNGTest {
    @Inject private Provider<Thing> thingProvider;
    private Thing thing;

    @BeforeTest
    public void doBeforeTest() {
        thing = thingProvider.get();
    }

I've used both, but I have to agree with Justin Standard that you shouldn't really consider rewriting your existing tests to any new format. Regardless of the decision, it is pretty trivial to run both. TestNG strives to be much more configurable than JUnit, but in the end they both work equally well.

TestNG has a neat feature where you can mark tests as a particular group, and then easily run all tests of a specific group, or exclude tests of a particular group. Thus you can mark tests that run slowly as in the "slow" group and then ignore them when you want quick results. A suggestion from their documentation is to mark some subset as "checkin" tests which should be run whenever you check new files in. I never saw such a feature in JUnit, but then again, if you don't have it, you don't REALLY miss it.

For all its claims of high configuration, I did run into a corner case the a couple weeks ago where I couldn't do what I wanted to do... I wish I could remember what it is, but I wanted to bring it up so you know that it's not perfect.

The biggest advantage TestNG has is annotations... which JUnit added in version 4 anyways.

Really Testng-y way to do this is to set ITestContext attribute with desired value and then get it from other test class.

Set value:

@Test
public void setvaluetest(ITestContext context) {
        String customerId = "GDFg34fDF";
        context.setAttribute("customerId", customerId);
}

Get value:

@Test
public void getvaluetest(ITestContext context) {
        String id = context.getAttribute("customerId");
}

Disclaimer: I'm the one who added the support of non static methods from external dataProvider.

Just add @Guice on your class:

@Guice
public class TestClass {
    @Test(dataProvider = "get", dataProviderClass=TestDataProvider.class)
    public void test1(String s1, String s2) {
        Assert.assertEquals(s1.length(), s2.length());
    }
}

It is a not yet referenced issue.

There's a feature that lets you set a tests severity: https://docs.qameta.io/allure/#_severity_3

I'm not aware of a way to show test status by severity in %. The "Graphs" category has a widget that comes close to it. It shows each test status in columns according to amount of tests. You can see how many tests failed, are brocken, etc for each level of severity.

There are 5 levels:

• blocker
• critical
• normal
• minor
• trivial

Example from the docs:

public class MyTest {
    @Test
    @Severity(SeverityLevel.CRITICAL)
    public void testSomething() throws Exception {
        // ...
    }
}

Annotation attributes can only be assigned constant expressions (and a few other types).

In Foo

public static final int timeLimit;

static{
    timeLimit=10000;
}

@Test(timeOut=timeLimit)

the variable timeLimit is not a constant expression.