Groups and inheritance
Eran
I think I have found a problem regarding the combination of groups and inheritance.
Suppose we have
@Test(groups = {"base"})
public class Base {
@Configuration(beforeTestClass = true)
public void baseSetup() {
System.out.println("base before class");
}
@Configuration(afterTestClass = true)
public void baseTeardown() {
System.out.println("base after class");
}
}
@Test(groups = {"sub"})
public class Sub extends Base {
@Configuration(beforeTestClass = true)
public void subSetup() {
System.out.println("sub before class");
}
@Configuration(afterTestClass = true)
public void subTeardown() {
System.out.println("sub after class");
}
public void subTest() {
System.out.println ("sub test");
}
}
Now, if we run *class* Sub we get
base before class
sub before class
sub test
sub after class
base after class
which is expected. However, if we run *group* sub the result is
sub before class
sub test
sub after class
which is not what I had in mind.
I should note that if we add group "sub" to the base class then the base class methods get invoked but that doesn't seem like the right thing to do.
I understand the base class methods need to belong to "sub" group for TestNG to run them, but isn't that implied by the fact that Sub extends Base and has a class level annotation?
Regards,
Eran
Barry Kaplan
public abstract class Fixturable {
@Conguration(beforeTest=true, groups="fixture")
public void setupFixture() { ... }
...
}
public void ConcreteTest extends Fixturable {
@Configuration(beforeTest=true, afterGroups="fixture")
public void afterFixture() { ... }
...
}
In the above, the method afterFixture runs /before/ the setupFixture method.
Before I submit a jira issue, might I be doing something wrong?
-barry
---------------------------------------------------------------------
Posted via Jive Forums
http://forums.opensymphony.com/thread.jspa?threadID=22816&messageID=44526#44526
Cédric Beust ♔
I am having a slightly different groups/inheritance problem:
public abstract class Fixturable {
@Conguration(beforeTest=true, groups="fixture")
public void setupFixture() { ... }
...
}
public void ConcreteTest extends Fixturable {
@Configuration(beforeTest=true, afterGroups="fixture")
I think TestNG should prohibit this... It's probably not always possible for a method to be "beforeTest" and "afterGroups", so no wonder TestNG gets confused.
I guess this is one more reason why I should deprecate @Configuration and introduce @BeforeTest and @AfterGroups... this way you won't be able to mix them any more.
Cédric
Cédric Beust ♔
What does everyone think?
If a base class declares a class-scoped annotation, should this annotation apply to all subclasses as well?
--
Cédric
Eran
@Test(groups = {"db"})
public class DBTest {
@Configuration(beforeTestClass = true)
public void connectToDB() {
//...
}
@Configuration(afterTestClass = true)
public void disconnectFromDB() {
//...
}
}
@Test(groups = {"db", "sql"})
public class SQLTest extends DBTest {
@Configuration(beforeTestClass = true)
public void createTable() {
//...
}
@Configuration(afterTestClass = true)
public void dropTable() {
//...
}
}
@Test(groups = {"db", "sql", "insert"})
public class InsertTest extends SQLTest {
public void testInsert() {
//query
}
}
If we want to run group "sql", we have to add "sql" to DBTest group list.
If we want to run group "insert", we have to add "insert" to both SQLTest and DBTest group list.
In general, we have to make sure every class in the inheritance hierarchy belongs to every group its descendants belong to.
Or am I missing something obvious here?
Regards,
Eran
Barry Kaplan
> introduce @BeforeTest and @AfterGroups... this way
> you won't be able to mix them any more.
But even so, why not support partial ordering of groups within a before/after context?
---------------------------------------------------------------------
Posted via Jive Forums
http://forums.opensymphony.com/thread.jspa?threadID=22816&messageID=44629#44629
Barry Kaplan
> should this annotation apply to all subclasses as well?
If it applies to a method, yes. My example is similar to standard junit idioms where an abstract test class would define hook methods. Of course my difficulties stem from that I'm trying to avoid the "big blob base test class" that has to accomadate thousands of tests.
(And even though most of my current examples have been small, the last trading system I built literally had 10k unit tests and 3k functional tests. The base class(es) for the functional test was a dumping ground. Most funtionality was only applicapable for a small number of tests. I'm hoping to use annotations and my experiment with mixin-fixtures to avoid that this time.)
---------------------------------------------------------------------
Posted via Jive Forums
http://forums.opensymphony.com/thread.jspa?threadID=22816&messageID=44630#44630
Cédric Beust ♔
Perhaps a more concrete example would make my point clearer.
I agree. I think the behavior you are expecting is the correct one, I'll fix that.
Cédric
Eran
Best regards,
Eran
Cédric Beust ♔
> I guess this is one more reason why I should deprecate @Configuration and
> introduce @BeforeTest and @AfterGroups... this way
> you won't be able to mix them any more.
But even so, why not support partial ordering of groups within a before/after context?
Please see my comment on the issue: you can interpret this in many different ways, you are much better off defining two distinct @Configuration methods, and then the semantic is clear...
http://jira.opensymphony.com/browse/TESTNG-52
Cédric
Alexandru Popescu
tia,
./alex
--
.w( the_mindstorm )p.
Cédric Beust ♔
Are you thinking in terms of using a specific annotation for each type (@BeforeSuite/@BeforeTest/etc)
Just deprecating @Configuration and creating corresponding annotations:
@BeforeSuite
@AfterSuite
...
--
Cedric
--
Cédric
Alexandru Popescu
> On 3/23/06, Alexandru Popescu <the.mindstor...@gmail.com> wrote:
>>
>> Are you thinking in terms of using a specific annotation for each type (@
>> BeforeSuite/@BeforeTest/etc)
>
>
> Just deprecating @Configuration and creating corresponding annotations:
>
> @BeforeSuite
> @AfterSuite
> ...
>
> --
> Cedric
>
>
I think this is a good option for this moment. Attributes are becoming too many and may lead to
confusion.