Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update MethodInvocationHelper.java #2040

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

sainjalpolys
Copy link

Fixes # .

Did you remember to?

  • Add test case(s)
  • Update CHANGES.txt

We encourage pull requests that:

  • Add new features to TestNG (or)
  • Fix bugs in TestNG

If your pull request involves fixing SonarQube issues then we would suggest that you please discuss this with the
TestNG-dev before you spend time working on it.

Copy link
Member

@krmahadevan krmahadevan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@sainjalpolys - Thanks for taking the time to submit the PR. But can you please help elaborate as to what is the issue that we are trying to fix in this PR ? Also please help add a test that vets out the change.

@sainjalpolys
Copy link
Author

sainjalpolys commented Mar 23, 2019

 private List<String> errorCodes = Arrays.asList("ERR100909", "ERR100");

    @Override
    public void run(IHookCallBack callBack, ITestResult testResult) {
        callBack.runTestMethod(testResult);
        Throwable t = testResult.getThrowable();
        if (t != null) {
            t = t.getCause();
        }

        boolean shouldFail = (t instanceof LocationBDLException&& errorCodes.contains(((LocationBDLException) t).getErrorCode()));
        if (shouldFail) {
            testResult.setThrowable(null);
            testResult.setStatus(ITestResult.SUCCESS);
        } else {
            testResult.setThrowable(t);
            testResult.setStatus(ITestResult.FAILURE);
        }
      
    }

    @Test()
    public void test1() throws LocationBDLException {
        throw new LocationBDLException("ERR100", "s", new Throwable());
    }

But while calling runTestMethod, It is catching the exception and setting the error variable in the catch block..

  @Override
      public void runTestMethod(ITestResult tr) {
        try {
          invokeMethod(thisMethod, testInstance, parameters);
        } catch (Throwable t) {
          error[0] = t;
          tr.setThrowable(t); // make Throwable available to IHookable
        }
      }

So even if we are setting the test result as success,

testResult.setThrowable(null);
testResult.setStatus(ITestResult.SUCCESS);

It will throw exception and test is getting failure

protected static void invokeHookable(final Object testInstance, final Object[] parameters,
      Object hookableInstance, final Method thisMethod, TestResult testResult) throws Throwable {
    Method runMethod = hookableInstance.getClass().getMethod("run",
        new Class[] { IHookCallBack.class, ITestResult.class });
    final Throwable[] error = new Throwable[1];

    IHookCallBack callback = new IHookCallBack() {
      @Override
      public void runTestMethod(ITestResult tr) {
        try {
          invokeMethod(thisMethod, testInstance, parameters);
        } catch (Throwable t) {
          error[0] = t;
          tr.setThrowable(t); // make Throwable available to IHookable
        }
      }

      @Override
      public Object[] getParameters() {
        return parameters;
      }
    };
    runMethod.invoke(hookableInstance, new Object[] { callback, testResult });
    if (error[0] != null) {
      throw error[0];
    }
  }

So we can avoid setting error[0] = t; and throwing exception from there class . .

@juherr
Copy link
Member

juherr commented Mar 23, 2019

That's strange it doesn't break tests. So I'm not opposed to the change. But it will break the backward compatibility.

private List<String> errorCodes = Arrays.asList("ERR100909", "ERR100");

    @Override
    public void run(IHookCallBack callBack, ITestResult testResult) {
        try { 
            callBack.runTestMethod(testResult);
        } catch(Exception e) {
            t = e.getCause();
        }

        boolean shouldFail = (t instanceof LocationBDLException&& errorCodes.contains(((LocationBDLException) t).getErrorCode()));
        if (shouldFail) {
            testResult.setThrowable(null);
            testResult.setStatus(ITestResult.SUCCESS);
        } else {
            testResult.setThrowable(t);
            testResult.setStatus(ITestResult.FAILURE);
        }
      
    }

    @Test()
    public void test1() throws LocationBDLException {
        throw new LocationBDLException("ERR100", "s", new Throwable());
    }

should have the behavior you expect too.

@krmahadevan I let you take the merge decision.

@krmahadevan
Copy link
Member

@juherr -

That's strange it doesn't break tests.

Perhaps there is no tests that is currently checking this ? That perhaps explains why there are no build breakages.

But it will break the backward compatibility.

Perhaps yes. But I guess we should be fine, because this is a new major version.

@sainjalpolys - Thanks for elaborating the issue. Can you please help add a test in test.hook.HookableTest that vets out your change ?
We also would like to ensure that the contributors get credited for their contributions. The usual practice is that, one creates a new issue (or) refers to an existing issue, in the CHANGES.txt file with a reference to the github issue and also the contributors name. I would leave it to you if you would like to go through with that or not.

But as soon as you can please help add a test, we should be able to get this changeset merged.

@juherr
Copy link
Member

juherr commented Mar 24, 2019

@sainjalpolys Is my solution working for you?

I found one of my old answers too: https://stackoverflow.com/q/38784823/4234729

@krmahadevan In fact, my surprise is because of the thrown exception is not useful for the internal flow. It means that with or without it TestNG is still working as expected.

I didn't find anything in the documentation or javadoc talking about the expected behavior. So we can decide to apply the change if wanted. I have no opinion about the best choice :)

Copy link
Member

@juherr juherr left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Tests are missing

@sainjalpolys
Copy link
Author

sainjalpolys commented Mar 25, 2019 via email

@sainjalpolys
Copy link
Author

sainjalpolys commented Mar 25, 2019 via email

@juherr
Copy link
Member

juherr commented Mar 26, 2019

@sainjalpolys

And Sorry.. your solution doesn't work for me..

Why? What is the behavior? The exception you removed is supposed to be caught now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants