--
You received this message because you are subscribed to the Google Groups "testng-users" group.
To post to this group, send email to testng...@googlegroups.com.
To unsubscribe from this group, send email to testng-users...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/testng-users?hl=en.
To unsubscribe from this group, send email to testng-users...@googlegroups.com.
Here is our workflow: every day many commiters submits their tests
code to SVN, then every night whole big test suite executed and at the
morning we are cheking results. So if someone will commit wrong test
(that throws exception in constructor), then we will not get results
of other correct tests, we will not get results at all, which means
that we lost 1 day of autotesting.
But if TestNG will mark that fail-initialized test as failed and
continue execution of other tests, everything will be OK - we will fix
incorrect test and check results of all other (correct) tests.
I doesn't mean situation when TestNG XML is not correct or something
wrong in environment, but only that situation when because of 1 wrong
test we lost results of all other tests.
--
You received this message because you are subscribed to the Google Groups "testng-users" group.
To post to this group, send email to testng...@googlegroups.com.
To unsubscribe from this group, send email to testng-users...@googlegroups.com.
Why do you think that it is correct TestNG's reaction? It is more user-
friendly to just log exception like all other exceptions and show it
in report. Any method can throw exception, but constructor can't...
what is the logic in this case?
Maybe it is different to implement in current TestNG architecture?
--
I don't mean to jump in the middle here, but can you explain why "StringIndexOutOfBoundsException" is not catchable?
Cédric, thanks for detailed answer.
I can't catch all such exceptions because them can be also trown on
class field definition, for example:
public class SomeTest {
private String s = "abc".substring(5, 10);
}
Creating of new instance of such class will throw
java.lang.StringIndexOutOfBoundsException: String index out of range:
10. And it can't be catched.
So what you want is for TestNG to ignore "bad" classes when collecting candidate tests, but carry on the test run and run tests in classes that do initialise correctly, because you work in and environment where you can't always guarantee that all classes will initialise cleanly?
Presumably you would want the overall result to be a Fail, but to receive detailed results for any tests that *did* run...
--
Bill Michell
billm...@gmail.com
> >>> A quick review on how to control this setting:
> >>> Command line: -configfailurepolicy continue|skip
> >>> testng.xml: <suite configfailurepolicy="continue|skip" ...>
> >>> Ant task: <testng configfailurepolicy="continue|skip" ...>
> >>> Feature recap: When configfailurepolicy is set to 'continue', TestNG
> >>> will continue to run any remaining tests that do not depend on the
> >>> "instance" of a configuration method that fails or encounters a
> >>> SkipException. For example, if a @BeforeClass method in a base class
> >>> with 2 subclasses fails when running for subclass 1, subclass 2 will
> >>> not be automatically skipped. (Subclass 1 will be skipped as
> >>> expected.) In a similar way, if a local @BeforeMethod method fails
> >>> for test 1, test 2 will not be automatically skipped. (Test 1 will
> >>> though.)
To unsubscribe from this group, send email to testng-users...@googlegroups.com.
Also, Martin in your case, try setting -configfailurepoilcy=true while running tests and see if that helps. I am guessing that you might have a single @BeforeClass method in a parent class and the test classes extend from this class.
To unsubscribe from this group, send email to testng-users...@googlegroups.com.
To unsubscribe from this group, send email to testng-users...@googlegroups.com.
Martin,
Again, you problem will be solved by setting -configfailurepolicy=continue while running tests from commandline. They way you have your code organized seems fine to me.
Cedric,
you wrote, "How do you expect code that is inherited by n classes from a base class to magically act differently when it's being run in a specific subclass?"
What about an abstract base class that has:
1. an abstract method annotated @BeforeClass
2. a method A() annotated as @BeforeClass which calls another abstract method B() which is implemented differently by subclasses.
public class SeleniumTest{@BeforeMethod(alwaysRun= true)public void initBrowser(Method method, Object[] parameters){try{// Some code here to init the browser}catch(Exception e){}}/*** This is a "BeforeInvocationMethod" defined by me.* An BeforeInvocationMethod is executed by TestMethodListener.beforeInvocation() right before the execution of a test and after of* BeforeMethods.* Will share the same prefix scheme with BeforeMethods and AfterMethods and must start with "beforeInvocation" in order to be* executed.* Would be useful to create an Annotation called BeforeInvocationMethod to formalize the concept.* */public void beforeInvocation1_checkBrowserIsInitalized(IInvokedMethod iInvokedMethod, ITestResult iTestResult, ITestContext iTestContext){synchronized(this){if(isBrowserInitialized() == false){throw new CouldNotInitBrowserException("The browser could not be initialized");}}}@Testpublic void testA(){}@Testpublic void testB(){}}
public class TestMethodsListener implements IInvokedMethodListener2{private static void executeBeforeInvocationMethods(IInvokedMethod iInvokedMethod, ITestResult iTestResult, ITestContext iTestContext){// Get all the methods of Test class (a subclass of BaseSeleniumTest) and select BeforeInvocationMethodsList<Method> methods_aux= Arrays.asList(iTestResult.getInstance().getClass().getMethods());List<Method> methods= new ArrayList<Method>();for(int i=0; i < methods_aux.size(); i++){if(methods_aux.get(i).getName().startsWith("beforeInvocation"))methods.add(methods_aux.get(i));}// Sort the methods by nameCollections.sort(methods, new MethodComparator());// Now execute all BeforeInvocationMethodsfor(Method m : methods){m.invoke(iTestResult.getInstance(), new Object[] {iInvokedMethod, iTestResult, iTestContext});}}public void beforeInvocation(IInvokedMethod iInvokedMethod, ITestResult iTestResult, ITestContext iTestContext){executeCustomeBeforeInvocationMethods(iInvokedMethod, iTestResult, iTestContext);}}
public class CouldNotInitBrowserException extends SkipException
{
private static final long serialVersionUID = -4309119505505201400L;
public FailException(String skipMessage)
{
super(skipMessage);
}
public FailException(String skipMessage, Throwable cause)
{
super(skipMessage, cause);
}
/**
* Please, see the documentation of SkipException.isSkip()
*/
public boolean isSkip()
{
return false;
}
}
Hi!
There is a bug in TestNG 5.13.1 (earler versions seems also affected).
In case if test class initialization failed, TestNG shows error like:
[testng] [ERROR]:
[testng] Cannot instantiate class xx.xx.XxTest
[testng] The tests failed.