--
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.
Cederic,
Sorry, I don't want to sound too rude, and you probably are busy
implementing tons of things that are much more important. But, just
curious, any idea when something like this will be available ?
Hi Cederic,
Thanks for the change, Yep notice the preference option.
The problem I am having with this change is that it's too global for me. I have many tests that I run within Eclipse (a few hunderd that I run as a package/group)... But I have only about 20 tests that I need a listener for and also about a hunderd that I need to give extra memory during there run. I don't want other tests to bother with this global settings.
I think we can solve this through Annotations like explained in my post. What do you think how I can asolve this?
The other advantage of using annotation is that people don't need to change there eclipse configuration....
I hope I don't sound too negative about the change :(
Ed
When running a test, the testNG test runner will then scan the class
and all super classes of the test method for these annotation(s) and
will use them in preference of the testNG xml file. And the
annotations in the subclasses can override annotated value's in super
classes. This latter overriding feature I use a lot during my tests
and works nicely as you can configure global tests settings in super
classes and subclasses can override parts or all of these settings.
These settings are those that I need at this moment:
- Listener to get informed about test result.
- Setting JVM parameters.
For me, setting these things through annotations, is the best way I
came up with. Through configurations files is too global and needs an
extra configuration step in your development environment that I don't
like. I mean: a new developer can easily forget to set these
configuration settings in his testNG preference and then it doesn't
work. With annotations, the test runner will automatically search for
them and use them.. No extra configuration needed.
Examples:
@TestNG(listener="com.bla.ListenerTestNG", JvmArgs="-Xms512m -
Xmx756m")
Or maybe it's better to split them up:
@Listener("com.bla.ListenerTestNG")
@JvmArgs("-Xms512m -Xmx756m")
I think I prefer this latter one (splitted up). To my experience this
works better due to the syntact/default value nature of annotation. I
started using annotation putting everyting in one, but nowedays prefer
using more small annotations...
What do you think?
--
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.
Interesting... I don't know exactly how the plugin works and how it
starts the tests. So the plugin does run the test directly but also
create a launch configuration?...
I hoped it would be something like: create the launch configuration
and tell Eclipse to run it. So the Annotation would just add the jvm
arguments to the launch configuration.... Is it possible through the
plugin to run tests like this: create launch config and tell Eclpse to
run it..?
What is the best way to add these jvm parameters then ?
> I still think that these two pieces of information are better described in
> the Eclipse launch configuration: when you are about to run a TestNG, this
Euuhhhh... I sometimes have to remove my testNG launch configurations
as there are about a hunderd of them in Eclipse. So as you can
imagine, configuring all these launch configurations to meet the
requirements doesn't really make me happy....
> So I was thinking of adding the same setting that I added globally to launch
> configurations so that you can override the template XML file there, I think
> it would solve your problems completely.
Yes, but that requires an extra step to run a test (in required
flexible way): to configure the launch configuration which I don't
want.
++++ Let go back to the original problem: launching a test in a user
friendly way that uses "common" settings.
---- By user friendly I mean: right clicking a method and running it,
and the common settings that are required to run the test correctly
are automatically used without performing an extra step.
What I understand from your post: the tester that runs the tests, has
to perform an extra step: modifying the launch configuration to meet
the required settings such that the test is run correctly. If he
launches 2 tests, or the failed tests, or the all tests in one
package, or all tests in one class, he has to modify all these
automatically created launch configuration. In our projects, that can
lead to duplicate modifications of maybe hundred launch configurations
:(
Even if the tester has knowledge of doing this: you can understand
that this is not an option.
Secondly, a tester and developer, that use both Eclipse have different
development knowledge and it's not acceptable to assume that a tester
knows anything about Eclipse launch configurations. They know who
configure the scripts, right click the method/class/package and run
the test....That's about it.. And I think is also the desired
situation. Why bother them with unnecessary things.
--- By common settings I mean: define commons settings per class at
least. This is exactly what you can do with an annotation and it keeps
it all together. These global settings are too common to use them for
all tests..
My point: how to define common settings for a "group" of test methods
such that the are automatically picked up when running a test through
the context menu (without the extra step)...
What could be an idea is adding an extra group and that this group
contains additional settings. But I am not sure if a group is suitable
for that.
I donnoooo...
How I run a test now, that needs extra jvm param's? Through the
context menu: run the test and stop it directly. Then go to the Run
configuration and change the jvm params of the just automatically
created test. Ofcourse I only do this once, but when I upgrade my
eclipse, or remove all my testNG launch configurations, I have to
start alllll over again... And believe me: that doesn't really make me
happy...
This doesn't sound like a healthy way of running your tests (method,
class, failed tests, package, etc...)
How can I improve this?
To keep it flexible: maybe it might be an idea to define an
interceptor through an annotation that will receive the test runner as
argument and in this way is offered to do what ever he wants with it.
For example: adding a listener such that you are informed if a test
fails or not... If the interceptor annotation is encountered, it will
use it, otherwise not of course...
Ed
>> testng-users...@googlegroups.com<testng-users%2Bunsu...@googlegroups.com>
>> .
>> For more options, visit this group at
>> http://groups.google.com/group/testng-users?hl=en.
>>
>>
>>
>
>
> --
> ***Cédric
> *
Just curious if you got time to look at my last post ?
Hi Cediric,
Just curious if you got time to look at my last post ?
--
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.
2010/1/7 Cédric Beust ♔ <cbe...@google.com>:
--
Although nobody can come back and make a new start, anyone can start
now and make a new end