CODEWITHSUNDEEP
javatestng
Nathan Merrill
Nathan Merrill

Reputation: 8396

TestNG skipping @Test, when dependent tests are marked as Pass

Here's my scenario:

In many of my tests, I may throw a PassedException (An exception I created that says that the test passed, but to stop the execution).

Originally, all of my tests had a expectedExceptions = PassedException.class, and threw a PassedException at the very end. I didn't like this solution.

I changed it so that in my TestListener, in the method onTestFailure(ITestResult result), I check to see the throwable type is PassedException.class, and if it is, call result.setStatus(ITestResult.SUCCESS).

This works...the tests are marked as passes, however, if another test depends on a method that threw a PassedException.class, then it will skip it.

Do any of you know why this is the case, and how to fix it (or a workaround)?

EDIT: Here is a duplicable case:

public class PassedException extends RuntimeException{}

public class Tester {

 @Test
 public static void test1(){
    throw new PassedException(); 
 }
 @Test(dependsOnMethods = "test1")
 public static void test2(){

 }
}

public class TestListener extends TestListenerAdapter {

 @Override
 public void onTestFailure(ITestResult result){
    Throwable t = result.getThrowable();
    if (t.getClass().equals(PassedException.class)){
        result.setStatus(ITestResult.SUCCESS);
    }
 }
}

Upvotes: 2

Views: 3827

Answers (1)

Pyranja
Pyranja

Reputation: 3599

I admit, that I do not fully understand the reasoning behind the PassingException, but I have two suggestions:

  • The workaround

    @Test(alwaysRun = true, dependsOnMethods = { "myFailingTest" })

This creates a soft dependency, i.e. the annotated test should be executed even if the tests it depends on failed/threw an exception (documentation). But that you encounter such a problem in the first case, indicates that there is either a bug in TestNG or your test design conflicts with the intended usage of TestNG. Using this workaround will imho hurt you in the long run.

  • Refactoring the tests

Using the expectedExceptions option is a sound approach to test fail-fast scenarios in an application. As far as I understand your use case, the key would be to narrow your tests in such a way, that there is just one possible outcome, i.e. in the given example you would have a test that emulates a "super user", where the awesome power button is available and does something awesome, which you assert. Then there is another test - emulating a "simple user" - where it is not available and you always expect a PassingException to be thrown.

Upvotes: 2

Related Questions