cbeust/testng-eclipse — Issue #47: test class inherit super class with @Test aren't recognized as test
Author: eddgrant
Created: 2012-01-12 15:58:05+00:00
State: open

Copying this from the Google Code issue tracker (http://code.google.com/p/testng-eclipse/issues/detail?id=63) as it doesn't seem to have been addressed but also doesn't seem to have been migrated to GitHub.

What steps will reproduce the problem?
1. create a base class
import org.testng.annotations.Test;

@Test
public class BaseClassTest {

}

2. create a sub-class

public class SomeTest extends BaseClassTest {

public void test1() {
// test something
}
}
3. try to run/debug the sub-class SomeTest from any context fails,
Some examples:
a- in the editor for SomeTest. right-click and select Run or Debug as..., the TestNG menu item doesn't show up
b- from the Debug Configuration UI, "new" a TestNG configuration, set corresponding project, and try to browse for classes, "SomeClass" won't show up.
c- in the package explorer, right-click the Sometest.java node, and do the same as aboce, again the menu item to launch TestNG doesn't show up

What is the expected output? What do you see instead?

I would expect the TestNG menu-item to show up so that a test can be launched on SomeTest. Instead the testng plug-in seems to ignore that this class implements a valid test and thus doesn't provide a menu-item to launch it.

We're trying to build our tests with testng. And since our system is quiet complex we're trying to capture some of the complexity in a base class that all developers could simply inherit from.

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

TestNG	6.2.0.20110905_0934	org.testng.eclipse.feature.group	Cedric Beust

Eclipse SDK
Version: 3.7.1
Build id: M20110909-1335

on Windows 7, 64 bits.

Please provide any additional information below.

I looked a bit at the plug-in source code. It looks like JDT core doesn't have a fast API to lookup the super types of a type (it seems you'd have to use an asynchronous search, which would probably be too slow for a UI gesture like this).
Of course there are workarounds, like putting @Test on the sub-class, but at this point we're still trying to come up with a programming model as lightweight as possible.

Note the above test case is an over simplification. In the real implementation @Test has more attributes (like dataProvider) that we'd prefer not to repeat for every single test.