Running a single method (with parameters) in eclipse is broken
MarkSwanson
I have moved everything into a single testng.xml file.
I have a single TestNG 5.2 config defined in eclipse that runs the
suite 'testng.xml'.
I see that when I try to run the single method the TestNG 5.2 plugin
creates a brand new temp-testng-customsuite.xml file with the correct
class/methods/include. All good, except that it didn't copy the
required parameters from the testng.xml file.
Is this a bug or by design? It would seem with this one minor fix it
would be possible to run a single test method (including dependencies
of course). Since it's temp file the easiest thing to do (it would
seem) would be to just copy all of the parameters from the specified
testng.xml file into the test xml file.
Thoughts?
Alexandru Popescu
Hi Mark!
I might have missed this one :-[ (even if I think I have worked on
it). Do you run the method by right-clicking it?
If you run the class by right clicking -> Run as -> TestNG test is the
temp file correct (does it contain the correct parameters)?
cheers,
./alex
--
.w( the_mindstorm )p.
TestNG co-founder
EclipseTestNG Creator
>
> >
>
MarkSwanson
selecting 'Run As', ->
TestNG. This does not build the temp file correctly with the 5.2
version. It should be easy to create a test to see this for yourself.
I also noticed something else. TestNG isn't handling the regular
expressions properly. For example, the following <test> says to include
everything. But the error is pasted below.
<test name="all">
<groups>
<run>
<include name=".*"/>
</run>
</groups>
<packages>
<package name=".*"/>
</packages>
</test>
[RunInfo] Adding method selector:
org.testng.internal.XmlMethodSelector@9664a1 priority: 10
===============================================
calendar suite
Total tests run: 0, Failures: 0, Skips: 0
===============================================
org.testng.TestNGException:
Cannot find class in classpath: .test.CSVTest
at org.testng.xml.XmlClass.getSupportClass(XmlClass.java:45)
at org.testng.internal.Utils.xmlClassesToClasses(Utils.java:82)
at org.testng.TestRunner.initMethods(TestRunner.java:278)
at org.testng.TestRunner.init(TestRunner.java:216)
at org.testng.TestRunner.init(TestRunner.java:187)
at org.testng.TestRunner.<init>(TestRunner.java:132)
at
org.testng.eclipse.runner.RemoteTestNG$2.newTestRunner(RemoteTestNG.java:76)
at
org.testng.SuiteRunner$ProxyTestRunnerFactory.newTestRunner(SuiteRunner.java:439)
at org.testng.SuiteRunner.privateRun(SuiteRunner.java:177)
at org.testng.SuiteRunner.run(SuiteRunner.java:142)
at org.testng.TestNG.createAndRunSuiteRunners(TestNG.java:958)
at org.testng.TestNG.runSuitesLocally(TestNG.java:920)
at org.testng.TestNG.run(TestNG.java:676)
at org.testng.eclipse.runner.RemoteTestNG.run(RemoteTestNG.java:85)
at org.testng.eclipse.runner.RemoteTestNG.main(RemoteTestNG.java:127)
The class file is there, and it is in the class path. It does not
contain any @Test annotations though. If that's the problem I would
consider that a bug; testng should just ignore the class if there are
no @Test annotations.
The reason why I'm using a ".*" structure is because:
1. The eclipse plugin doesn't let me use multiple XML files - I can
specify specific ones, but right-clicking on the method and executing
it always picks the wrong xml file - discussed previously.
2. since (wrt the eclipse plugin) I can only have a single testng.xml
file for the entire project, I don't want to copy 50k lines of <test>
definitions in a single file. For eclipse purposes, I can not think of
a use case where the testng.xml needs anything else defined (other than
.*) because the plugin creates its own 'perfect' xml file and uses that
anyway.
Cheers.
Alexandru Popescu
> selecting 'Run As', ->
> TestNG. This does not build the temp file correctly with the 5.2
> version. It should be easy to create a test to see this for yourself.
>
In fact I have such tests, and they are working as expected. Even
more, if the project contains multiple suite definition files, I am
pointed to choose from the existing ones.
The only thing I can think of is that I may be using a more uptodate
plugin version, but I really doubt it.
I am looking into this.
> The reason why I'm using a ".*" structure is because:
>
> 1. The eclipse plugin doesn't let me use multiple XML files - I can
> specify specific ones, but right-clicking on the method and executing
> it always picks the wrong xml file - discussed previously.
I am still not sure about this, and I couldn't reproduce it (I checked
it twice during the last flight :-) ).
> 2. since (wrt the eclipse plugin) I can only have a single testng.xml
> file for the entire project, I don't want to copy 50k lines of <test>
> definitions in a single file. For eclipse purposes, I can not think of
> a use case where the testng.xml needs anything else defined (other than
> .*) because the plugin creates its own 'perfect' xml file and uses that
> anyway.
>
I am not sure about the above reason. Is it related to 1/ ?
./alex
--
.w( the_mindstorm )p.
TestNG co-founder
EclipseTestNG Creator
> Cheers.
>
>
> >
>
Alexandru Popescu
have used for the package the following .* TestNG doesn't allow this
regexp usage. You can specify a package: abc.def or a package and all
its subpackages: abc.def.*, but these 2 are the only available
options.
HTH,
./alex
--
.w( the_mindstorm )p.
TestNG co-founder
EclipseTestNG Creator
On 10/1/06, MarkSwanson <ma...@scheduleworld.com> wrote:
>
MarkSwanson
Thank you.
MarkSwanson
Alexandru Popescu wrote:
> On 10/1/06, MarkSwanson <ma...@scheduleworld.com> wrote:
> >
> > Yes, I run it by right-clicking the method from the Outline view and
> > selecting 'Run As', ->
> > TestNG. This does not build the temp file correctly with the 5.2
> > version. It should be easy to create a test to see this for yourself.
> >
>
> In fact I have such tests, and they are working as expected. Even
> more, if the project contains multiple suite definition files, I am
> pointed to choose from the existing ones.
Well, that sounds perfect. I wonder why my system works slightly
differently.
> The only thing I can think of is that I may be using a more uptodate
> plugin version, but I really doubt it.
I thought I read another post that you may have fixed this in CVS HEAD.
Maybe that's it?
> > The reason why I'm using a ".*" structure is because:
> >
> > 1. The eclipse plugin doesn't let me use multiple XML files - I can
> > specify specific ones, but right-clicking on the method and executing
> > it always picks the wrong xml file - discussed previously.
>
> I am still not sure about this, and I couldn't reproduce it (I checked
> it twice during the last flight :-) ).
Oh, neat.
Since I applied the new regex (com.wss.*) I can right-click and run an
event perfectly. (However, the parameters aren't copied into the temp
testng.xml file.) In any case, at what point would the eclipse plugin
ask me which testSuite*xml file to load?
Thanks.
Alexandru Popescu
After you right clicked -> Run as TestNG. At that moment, I am
building the launch configuration, and part of this process is to
analyse the type/method that is gonna be run. If it requires
parameters than I am looking for suite definition files in the
project. If I am finding more than one, than I ask the user to point
which one must be used.
I am wondering if you can paste here your method, so that I can throw
it in my Eclipse and see what is happening.
Here is an example I was using to test the plugin:
[code]
@Test
@Parameters({"coke", "cola"})
public void cokeMethod(String one, String two) {
Assert.assertEquals(one, two);
}
[/code].
HTH,
./alex
--
.w( the_mindstorm )p.
TestNG co-founder
EclipseTestNG Creator
> Thanks.
>
>
> >
>
mm
test method that I want to run with a few @BeforeTest or @BeforeMethod
methods that will also be run as a result. One of those (a @BeforeTest
method defined in a superclass) requires parameters.
When I select my single method to run, I am not prompted for any
parameter values, nor are they copied from the existing testng.xml.
Alexandru Popescu
I am aware of this problem, but unfortunately I haven't figured out a
good way to solve it. Maybe you can create an issue on JIRA to track
this one (or I can do it at some later point).