[testng-dev] Experience with new kind of @Test

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

[testng-dev] Experience with new kind of @Test

and.or
Hi Everyone!

 I am new here. Some month ago I found TestNG and I like to use it in my small personal projects. Now I want to experience with the implementation itself. I would like to create a new kind of test. Like @NewKindTest instead of @Test. Could anyone please show me some information, indications? Where to look at? How the TestNG interprets @Test annotation, what should I modify? 

Thanks in advance;
AndOr

--
You received this message because you are subscribed to the Google Groups "testng-dev" group.
To view this discussion on the web visit https://groups.google.com/d/msg/testng-dev/-/R7d-Kl3gpjUJ.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/testng-dev?hl=en.
Reply | Threaded
Open this post in threaded view
|

Re: [testng-dev] Experience with new kind of @Test

Cédric Beust ♔-2
Hi,

The short answer is that this is pretty much impossible since TestNG uses this annotation everywhere, so adding a different one would be a lot of work (and I'm not sure it's necessary either).

What are you trying to do exactly with this new annotation?

-- 
Cédric




On Tue, Jul 17, 2012 at 2:31 PM, and.or <[hidden email]> wrote:
Hi Everyone!

 I am new here. Some month ago I found TestNG and I like to use it in my small personal projects. Now I want to experience with the implementation itself. I would like to create a new kind of test. Like @NewKindTest instead of @Test. Could anyone please show me some information, indications? Where to look at? How the TestNG interprets @Test annotation, what should I modify? 

Thanks in advance;
AndOr

--
You received this message because you are subscribed to the Google Groups "testng-dev" group.
To view this discussion on the web visit https://groups.google.com/d/msg/testng-dev/-/R7d-Kl3gpjUJ.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/testng-dev?hl=en.

--
You received this message because you are subscribed to the Google Groups "testng-dev" group.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/testng-dev?hl=en.
Reply | Threaded
Open this post in threaded view
|

Re: [testng-dev] Experience with new kind of @Test

Mark Derricutt
One thing I -think- And Or is wanting is something I've been thinking about off and on for awhile.

An idea that's been floating in my mind lately for integration other test frameworks ( such as Cucumber, Concordion ) more easily is some form of "single method test class" for use mainly in factories, i.e. a flow something like:

1) Expose TestNG's classpath scanner as a reusable API
1) Class with @Factory requests TestNG to find classes with @WhatEverMyAnnotationIs
2) Instantiate a subclass of SingleAbstractTest for each discovered test passing it the discovered test class
3) return Iterable<? extends SingleAbstractTest> from the factory ( I'm not sure if  ITestClass that could be used here or not? )

Currently, TestNG reports a classname of a test as the .class of whatevers returned from the @Factory directly, I think it'd be nice if that could programatically controlled.

When I was trying to integrate cucumber this way, the TestNG reports all came as with "com.talios.CucumberTest" - it would be nice to control that and return "nousers.scenario" instead.





On Wed Jul 18 16:03:32 2012, Cédric Beust ♔ wrote:

Hi,

The short answer is that this is pretty much impossible since TestNG
uses this annotation everywhere, so adding a different one would be a
lot of work (and I'm not sure it's necessary either).

What are you trying to do exactly with this new annotation?

--
You received this message because you are subscribed to the Google Groups "testng-dev" group.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/testng-dev?hl=en.
Reply | Threaded
Open this post in threaded view
|

Re: [testng-dev] Experience with new kind of @Test

and.or
Hi,

 The idea is similar to one that Mark mentioned. But the focus was only on one framework.

 Long story short: I rewrote the QuickCheck[1] Haskell library in Java. You probably already heard about it, It is an automatic test case generation library and testing tool. And I would like to add it as an extension (or something similar) to TestNG as an experiment. The QC approach is used to define algebraic properties, invariants of functions, methods and modules. Somewhere lies between Unit testing, TDD, and Integration Testing.

 I tried to combine other existing implementation of Java QuickCheck like[2] with TestNG, but the the details got lost in the tremendous workaround in real life problems. My goal was to create the most readable test cases using this approach. On other hand, main things that are useful are still waiting for implementation in other QuickCheck frameworks [3][4] , such as shrinking the generated data into the most smallest form when a test fails, facilitate the debugging. I have this already done.

  An example: http://pastebin.com/FChV6Erw The @Property (a hardly overloaded name, it would be necessary the find a proper one) annotation would stand for the new test type, that the engine runs the given times. Using the @DataGenerator annotation we define the data generator for the given parameter of the test method. And @Shrink defines how the parameter gets simplified when the test fails searching the minimal test data that still holds the falsifiable property. In the example; testing the property2 the test will fail after having run some cases, and the data will shrinked to parameter1:51.

 In short terms; I would like to integrate the already written engine to TestNG. The approach is similar to @DataProvider, but it needs a testing loop running and evaulating the results, shrinking data, etc.
 

[1] http://en.wikipedia.org/wiki/QuickCheck
[2] http://java.net/projects/quickcheck/pages/Home
[3] http://java.net/projects/quickcheck/sources/repository/content/todo.txt
[4] http://www.jcheck.org/


Best Regards,
AndOr


On Wednesday, July 18, 2012 6:23:30 AM UTC+2, Mark Derricutt wrote:
One thing I -think- And Or is wanting is something I've been thinking about off and on for awhile.

An idea that's been floating in my mind lately for integration other test frameworks ( such as Cucumber, Concordion ) more easily is some form of "single method test class" for use mainly in factories, i.e. a flow something like:

1) Expose TestNG's classpath scanner as a reusable API
1) Class with @Factory requests TestNG to find classes with @WhatEverMyAnnotationIs
2) Instantiate a subclass of SingleAbstractTest for each discovered test passing it the discovered test class
3) return Iterable<? extends SingleAbstractTest> from the factory ( I'm not sure if  ITestClass that could be used here or not? )

Currently, TestNG reports a classname of a test as the .class of whatevers returned from the @Factory directly, I think it'd be nice if that could programatically controlled.

When I was trying to integrate cucumber this way, the TestNG reports all came as with "com.talios.CucumberTest" - it would be nice to control that and return "nousers.scenario" instead.





On Wed Jul 18 16:03:32 2012, Cédric Beust ♔ wrote:

Hi,

The short answer is that this is pretty much impossible since TestNG
uses this annotation everywhere, so adding a different one would be a
lot of work (and I'm not sure it's necessary either).

What are you trying to do exactly with this new annotation?

--
You received this message because you are subscribed to the Google Groups "testng-dev" group.
To view this discussion on the web visit https://groups.google.com/d/msg/testng-dev/-/EcI6NBrjb60J.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/testng-dev?hl=en.
Reply | Threaded
Open this post in threaded view
|

Re: [testng-dev] Experience with new kind of @Test

Davide Del Vento-3
> On other hand, main things that are useful are still waiting
> for implementation in other QuickCheck frameworks

I always wondered why and always hoped that "somebody" would fix it.
Great that you did! And great that you are proposing integrating it
into an existing framework instead of rolling your own.

I don't know enough about TestNG internals to comment on your specific
issues, but I would love to see your work integrated into TestNG.


>  An example: http://pastebin.com/FChV6Erw

Very cool! But I would like more (syntactic) sugar

Can't you use some reflection to make the
"@Shrink(IntegerShrink.class) @DataGenerator(IntegerGenerator.class)
int parameter1" less verbose? I mean, if parameter1 is "int" of course
@Shrink should be from IntegerShrink.class and @DataGenerator should
be from IntegerGenerator.class. IMHO "@Shrink @DataGenerator int
parameter1" reads *much* better. I would go even one step further and
say that shrink should be and option of @DataGenerator (and should be
on by default), so that we would have simply "@DataGenerator int
parameter1" most of the times and "@DataGenerator(shrink=false) int
parameter1" the rare cases in which we don't want to shrink.

Thanks for considering these suggestions and good luck integrating it
into TestNG!

Cheers,
Davide

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