Junit testing configuration & J2EE

Florian Hehlen wrote:

I have a lot of JUnit test cases that only work while running within a server context... and they create a lot of noise evry time I want to run all tests.

You could try creating a TestSuite class which only contains the test
cases that work outside of the server context, and then run the
TestSuite instead of "All in package".

Ciao,
Gordon

--
Gordon Tyler (Software Developer)
Quest Software <http://java.quest.com/>
260 King Street East, Toronto, Ontario M5A 4L5, Canada
Voice: (416) 933-5046 | Fax: (416) 933-5001

hi.

&gt; You could try creating a TestSuite class which only
&gt; contains the test
&gt; cases that work outside of the server context

Yes this is a possibility. But TestSuites are one more file to maintain. And they it's very tedious to check if a TestSuite covers all tests. Specially with group development.

Florian

I have a lot of JUnit test cases that only work while
running within a server context... and they create a
lot of noise evry time I want to run all tests.

I thought that this was defined as integration tests. When
I run these kind of tests it's usually Cactus tests and I
have them in a different source tree because they are
actually a different kind of beast.

-

Trond

&gt; I run these kind of tests it's usually Cactus tests
&gt; and I
&gt; have them in a different source tree because they are
&gt; actually a different kind of beast.

Well sure. I would like it to be that way to. But we do not use a directory structure here to differentiate integration from unit tests. plus, philosophically, it's not because a test requires a J2EE context that it's not a unit test. But that's besides the point.

It seems to me that it would be useful to be able to define subsets of tests based on filters. I am sure that people with 1000s of test classes do not right tests suites for every subset of tests they want to run.

Florian Hehlen

Florian Hehlen wrote:

Yes this is a possibility. But TestSuites are one more file to maintain. And they it's very tedious to check if a TestSuite covers all tests. Specially with group development.

Yeah. I haven't figured out a way of making TestSuite maintenance
easier. If anybody has any suggestions, I'd love to hear them.

Another suggestion is use a special subclass of TestCase (or just a
tagging interface) for the server-dependent test cases and the TestSuite
dynamically constructs its suite by looking for these specially marked
classes.

Ciao,
Gordon

--
Gordon Tyler (Software Developer)
Quest Software <http://java.quest.com/>
260 King Street East, Toronto, Ontario M5A 4L5, Canada
Voice: (416) 933-5046 | Fax: (416) 933-5001

A minimal workaround would be "test all in directory", rather than "test all in package". That way unit tests and system/integration tests could be put in different directories (but the same package), and it would be trivial to run all unit tests in a package from the Project view. The fact that the Project view acts differently for tests than it does for everything else is one of those rare niggling things about IDEA that simply drive me up the wall.

--Dave Griffith

hi

I also have a partial work around. It's a testSuite that actually searches the classpath for classes and then I use reflection to test that they are instances of known testing subclasses.

My problem at the moment is that the module architecture in IDEA seems to translate to one class loader per module because my code never seems to be able to find tests in any other context than the module I specify in the Run Configuration. This, even if I am running from within a module that has dependencies on all others.

Moving/merging modules in not something I can do.

Here is the code... if someone has any suggestions. If I could get this to search all classloaders in a jvm then it would not be hard to also add some file name filtering:

Florian

I have been using an junit extension named junit-addons that facilitates dynamic construction of test suite from test patterns. Its performance is ok but obviously not as good as static suites. You can define your own filter to implement even the most complicated patterns ;)

http://sourceforge.net/projects/junit-addons

Jacques

hi.

Have tried to use this tool. Seems to be exactly what I need. But I am getting classloading problems. Any idea why? I have included the stacktrace below.

Florian

stacktrace:

ok found my own problem:



I was setting the search path in the builder to the package from where I wanted the search to start... and not from the classpath root. So, instead of loading com.gcb.dgw.api.base.support.AbstractEnumerationTest it was trying to load api.base.support.AbstractEnumerationTest.

anyways.... this junit extention is quite sweet... just what the doctor ordered.

Florian