Unit tests in the same package?

[bosschaert]

Just wondering about the general convention for unit tests...

Typically  in other projects I have seen pure unit tests in the same package as  the class that they are testing, so e.g.:
  src/main/java/org/acme/MyClass.java
  src/test/java/org/acme/MyClassTest.java

It  has a number of advantages:

• It's really easy to find the unit  tests
• It also makes it easy for your test to access package  protected members. Making things package protected is usually harmless  from a backward compatibility pov, but it can be really handy for unit  tests if structured like this...

I notice that this convention  isn't really followed, at least not for the jboss osgi code.

Should  we maybe start doing this?

[alesj]

Typically  in other projects I have seen pure unit tests in the same package as  the class that they are testing, so e.g.:

  src/main/java/org/acme/MyClass.java
  src/test/java/org/acme/MyClassTest.java

It  has a number of advantages:

• It's really easy to find the unit  tests
• It also makes it easy for your test to access package  protected members. Making things package protected is usually harmless  from a backward compatibility pov, but it can be really handy for unit  tests if structured like this...

I notice that this convention  isn't really followed, at least not for the jboss osgi code.

IMO, this is a useless or even bad way of doing things.
(a) we mostly test security on all our code -- via simple policy that disables security for org.jboss.test.*, but enforces it for everything else
(b) i'm not buying the protected access argument; i think it's even good not to have it, you mock the user better that way
(c) never had problems finding right tests; some common sense should be applied to naming, but that's mostly it
(d) IDE refactoring is harder, as most IDEs "understand" it as part of same package
(e) ...

Should  we maybe start doing this?

I would say no.

Slightly on and off the subject -- since I already mentioned (a).

How do we take care of this security testing in new non-JBossTest based test env?

[bosschaert]

Thanks for the response, Ales. I'm slightly reordering them in my reply...

(b) i'm not buying the protected access argument; i think it's even good not to have it, you mock the user better that way

Well, I think there are many types of tests, all of which can be written using JUnit code. What I was referring to in my original post was pure unit tests by which I mean testing purely one unit. These tests should be able to test the internals of the unit IMHO which is often not possible just with its public API. Take for example a caching module. It would be pretty much impossible to test this only with its public API as you really want to probe some internals to see whether the caching is done properly.

Don't get this the wrong way, I don't discount functional tests, which should be run from a user's point of view. I just see the pure unit tests as an additional set of tests, which give you the assurance that the unit's internals behave as expected...

(a) we mostly test security on all our code -- via simple policy that disables security for org.jboss.test.*, but enforces it for everything else

I can see the security feature being very useful for functional tests, but don't fully see yet how it would apply to the pure unit tests...

(c) never had problems finding right tests; some common sense should be applied to naming, but that's mostly it

Well... ahem... maybe that's because you're involved for so long already? In general I think we should come up with a simple transformation from Fully Qualified Classname -> Fully Qualified TestClassName for pure unit tests. Functional tests should be ordered by functionality as they normally span multiple classes and packages...

(d) IDE refactoring is harder, as most IDEs "understand" it as part of same package

Why is this harder? Granted, if you change the package name of your original package the name of the associated test package might follow suit depending on the IDE settings. Why is that a problem?

(e) ...

Should  we maybe start doing this?

I would say no.

I buy your point on functional tests, which should probably in a separate module. It seems like a lot of the tests that are currently in jbosgi-framework/bundle would fit with what I think of as functional tests. I still think that there needs to be a place for the pure unit tests, like AutoInstallPluginTest.java which I still think would be great to have in the same package under src/test/java...

Slightly on and off the subject -- since I already mentioned (a).

How do we take care of this security testing in new non-JBossTest based test env?

Should this maybe be put in a separate discussion thread?