vladblaj / testng-idea

Automatically exported from code.google.com/p/testng-idea
0 stars 0 forks source link

Running a group runs its @BeforeGroup method twice #12

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?

1. Install the plugin
2. Replace the copy of testng that comes with the plugin with 5.5 beta
built from current source
3. Make some test classes:

public class BaseTest {
    @BeforeGroups( groups = "foo" )
    public void beforeGroups() {
        System.out.println( "beforeGroups" );
    }
}

@Test( groups = "foo" )
public class TestTest extends BaseTest {
    @Test()
    public void test() {
        System.out.println( "test" );
    }
}

java -cp (TestNG jar, Idea class output dir) org.testng.TestNG -testclass
TestTest prints "beforeGroups" once before printing "test"
java -cp (TestNG jar, Idea class output dir) org.testng.TestNG -testclass
TestTest -groups foo does the same

In the plugin, control-shift-F10 on the class (or the method) prints
"beforeGroups" once. However, if I make a config that runs the group "foo",
I see "beforeGroups" TWICE. I believe running the group foo via the plugin
should do the same thing as the second command line above, i.e. run
beforeGroups only once.

If beforeGroups is in TestTest rather than in a superclass, running the
test in the plugin only gives me "beforeGroups" once, regardless whether I
run the class or the group. So it looks like the plugin is doing the wrong
thing by superclasses somehow.

If I don't upgrade the copy of testng that comes with the plugin, I see
"beforeGroups" twice whether I run by method, class or group.

What version of the product are you using? On what operating system?

Plugin 0.5.5, testng 5.5 beta, Idea 6.0.4, MacOS X 10.4.8

Original issue reported on code.google.com by dschweis...@gmail.com on 18 Jan 2007 at 7:05

GoogleCodeExporter commented 9 years ago
beforeClass also runs twice if I control-shift-F10 on the package.
beforeClass still runs twice if I move the group declaration to the test thus:

public class TestTest extends BaseTest {
    @Test( groups = "foo" )
    public void test() {
        System.out.println( "test" );
    }
}

I tried this because it was a workaround for the bug Cedric just fixed in 
TestNG, but
it doesn't seem to matter here.

Original comment by dschweis...@gmail.com on 18 Jan 2007 at 9:10

GoogleCodeExporter commented 9 years ago
The problem is that the IDEA plugin scans the project for all test classes in 
the
classpath, which include both BaseTest and TestTest.  The @BeforeGroups 
annotation on
the BaseTest is inherited on in TestTest - so theres in effect TWO copies of
@BeforeGroups, hence you see it printed twice.

This is known/common problem of using such methods on superclasses - its not 
really a
bug, but unexpected behaviour.

Original comment by tal...@gmail.com on 19 Jan 2007 at 11:19

GoogleCodeExporter commented 9 years ago
Mark pointed out in the forum that the base class was abstract. It shouldn't 
have
been; that was a mistake I made when shrinking my real tests to test cases for 
this
bug. Making the base class abstract fixes the exact problem reported above. 
However,
it doesn't fix the problem if BaseTest has more than one subclass, which of 
course is
why it exists. Putting @BeforeGroups in a superclass of the tests that need its 
setup
seems like the only reasonable way to use it for once-per-group test field
initialization. Also, command-line TestNG doesn't run a @BeforeGroups method for
every subclass, and it seems like all test runners ought to follow the same 
rules.
Putting it that way, does it seem like any more of a bug?

Original comment by dschweis...@gmail.com on 22 Jan 2007 at 11:53

GoogleCodeExporter commented 9 years ago
To recap some discussion from the forum: I'd been using the wrong command line 
to
check TestNG's behavior. When I used the right command line, I saw the 
@BeforeGroups
method run twice when I ran a group of two BaseTest subclasses. Cedric fixed 
that
problem. Upgrading the TestNG jar in the plugin to one with Cedric's fix fixes 
the
problem in the plugin. So the change needed is just to include a new TestNG jar 
in
the plugin.

Original comment by dschweis...@gmail.com on 24 Jan 2007 at 6:59