Rules for TestNG

[Stefan Wolf]

Hi,

the only feature missing to TestNG compared to JUnit was Rules
support. But this is very easy to implement using the Standard
Listeners. I coded a prototype on GitHub: https://github.com/wolfs/testng-rules
The Feature is in the main folder and the tests implement some
examples, e.g. a Spring Rule making the AbstractTestNGSpring... base
class obsolete.
A nice feature is also that you can also have BeforeClass in a Rule,
so even more feature than JUnit Rules.
Please check and include (a probably more elaborate version) in TestNG
core.

Best regards,
Stefan

[Cédric Beust ♔]

Hi Stefan,

Interesting!

Could you add a README to your project on github to give a quick sense of what this looks like?

I understand the appeal of rules conceptually (you define an entire configuration with one object) but I've always objected to JUnit's implementation because their rules are scoped to the class, which severely limits their usefulness.

With TestNG, it should be easy to create rules that can be scoped at any level that TestNG supports (method, class, group, test or suite), which would make them extra powerful.

-- 

Cédric

--
You received this message because you are subscribed to the Google Groups "testng-dev" group.
To post to this group, send email to testn...@googlegroups.com.
To unsubscribe from this group, send email to testng-dev+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/testng-dev?hl=en.

[Stefan Wolf]

I added a README to the project with a small example. More examples
how to use this rules are in the src/test folder.

About scoping of rules: If you need a higher level like group or
suite, then fields are not suited very well to do this. I think in
this case the good old TestNG listeners would work directly. For
fields you can basically add discovery of all already present TestNG
Listeners. The main advantage of these rules is that they can have
state associated with the class under test, so in my opinion they are
not so interesting on a group or suite level.

--
Stefan

[Ansgar Konermann]

Am 10.06.2011 20:14, schrieb Stefan Wolf:
> I added a README to the project with a small example. More examples
> how to use this rules are in the src/test folder.
>
> About scoping of rules: If you need a higher level like group or
> suite, then fields are not suited very well to do this. I think in
> this case the good old TestNG listeners would work directly. For
> fields you can basically add discovery of all already present TestNG
> Listeners. The main advantage of these rules is that they can have
> state associated with the class under test, so in my opinion they are
> not so interesting on a group or suite level.

Hi all,

I'm not so sure listeners are the best solution here, at least with the
current implementation. I tried to do 'interception' using listeners and
finally ended up implementing IHookable as interception mechanism for
these reasons:
- listeners have to be configured in your IDE and your maven/ant/...
project files to work at all whereas extending a (lean) common
superclass which does the "magic" of intercepting the test method call
is far easier for the average developer.
- I found error reporting/logging from within a TestNG test listener to
be failure-prone (swallowed exceptions, lack of knowledge how to use
TestNG logging)
- debugging listener code from within an IDE is harder than debugging an
IHookable (at least with my setup using Jetbrains IDEA; the TestNG
version included with the IDEA distro must exactly match the version
used to develop the listener, otherwise the debugger will show wrong
source code when stepping through the listener code).

Nevertheless, I'm looking forward to seeing an elaborate interception
mechanism in TestNG. If I may (partly) repeat my most intimate wishes
regarding this topic ;-)
- make TestNG capable of interpreting "Meta-Annotations", make @Test a
meta-annotation
- allow definition of custom annotations to mark a test class as a test
of a certain kind, using @Test meta annotation to tell TestNG the
annotation carrying this meta annotation will make a java class a TestNG
test class with special roles, e. g. @SeleniumTest
- associate this custom annotation with some custom java code, say
@InterceptorImpl(SeleniumSuiteInterceptor.class), which is called at
defined points in time (e. g. if custom annotation carries @BeforeMethod
meta annotation, the associated code will be called before each test
method; @BeforeSuite could be made a meta-annotation to call the
relevant code before the beginning of a suite and so on).

Best regards

Ansgar

[Cédric Beust ♔]

Hi Stefan,

On Fri, Jun 10, 2011 at 11:14 AM, Stefan Wolf <glow...@gmail.com> wrote:

I added a README to the project with a small example. More examples
how to use this rules are in the src/test folder.

About scoping of rules: If you need a higher level like group or
suite, then fields are not suited very well to do this.

True, but I was thinking these more general rules could be defined elsewhere, such as testng.xml.

 

I think in
this case the good old TestNG listeners would work directly. For
fields you can basically add discovery of all already present TestNG
Listeners. The main advantage of these rules is that they can have
state associated with the class under test, so in my opinion they are
not so interesting on a group or suite level.

Fair point. I'm also a bit unclear on the amount of overlapping there might be between TestNG's listeners and rules whose granularity is broader than class.

-- 

Cédric

[Cédric Beust ♔]

Nothing planned in this area at the moment.

-- 

Cédric

On Wed, Oct 21, 2015 at 1:55 PM, Nat <nat....@gmail.com> wrote:

Apologies for digging up an old thread. I would like to follow up where TestNG is planned to go with @Rule and RuleChain.

[Nat]

Apologies for digging up an old thread. I would like to follow up where TestNG is planned to go with @Rule and RuleChain.

On Monday, June 13, 2011 at 1:01:16 PM UTC-7, Cédric Beust ♔ wrote: