Bug 163824

I forgot to say in my last comment that in fact I think that will be good for that class to have less dependencies to be
able to be used for other test frameworks like TestNG

Unclear if this is even possible to fix: JUnit 3 allows you to return a Test from a suite() method according to
arbitrary calculations, which NbModuleSuite's existing API relies on, whereas JUnit 4 seems to rely on annotations.
Perhaps it would be possible to have a parallel API:

@RunWith(NbModuleSuite4.class)
@NbModuleSuite4.Config(clusters=".*", modules=".*", gui=false)
public class MyFuncTest {
  @Test public void first() {...}
  @Test public void second() {...}
}

Of more concern is whether any of the useful functionality in NbTestCase (used also by unit tests) would survive.
Potentially a lot of work to make this happen; may be WONTFIX since the existing JUnit 3-based idioms work, even with
JUnit 4 in the classpath.

I do not find the benefits of JUnit4 (except of full compatibility with JUnit3) tempting enough to work on this issue.

I understand that his is not a priority one but I think that functionality like the @BeforeClass will simplify tests
because now I don't know how to reproduce easily with the existent solution. Also I think that some work needed here
will allow to use other test frameworks for functional tests.

And about implementation details:
By now the platform works well for Junit4 tests, the major problem is only the runInRuntimeContainer method that it's
coupled with TestCase. 
I think that a solution could be implement a NBModuleSuite4 with syntax like Jesse said. And that class could extend
BlockJUnit4ClassRunner or similar and override only the run() or runChild() to inject the platform start
(runInRuntimeContainer code).

Althouth I've to confess that I'm not a platform nor a Junit expert it seems to me more a refactor job making the
runInContainer not dependent of TestCase and outside of the NbTestSuite than an big design one.
But of course sometimes the evil is in the details ;)
That also will open the door to make functional tests with other frameworks like XTest, that I've seen that there is
some work for upcoming versions...

And about the functionality in NBTestCase I think that it's a minor issue at least for platform apps.
But a solution could be to make a NBAssert class to be used with static imports that delegates to static utility methods.

Using a static import for NbTestCase assertion methods is trivial. I was referring to other important functionality
which is tightly bound to JUnit 3 APIs and might not be trivially ported to JUnit 4 runners: runInEQ, timeouts, log
capture on failure, @RandomlyFails, etc.

Potentially a lot of work, with only modest benefit. I don't think anyone has the time to do this. In the meantime, if you want to take advantage of most of the features of nbjunit you must write JUnit 3.x-format tests.