--
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.