18

We're actually naming our test packages just like their to-test counterparts. So we end up with this structure: 

src/main/java
    com.hello.world
        helloWorld.java
src/test/java
    com.hello.world
        helloWorldTest.java

I always felt like this is not pretty smart since you can't distinguish between "test" and "to-test" if only provided with the package name. On the other hand I haven't really found a case where this matters somehow. Is it a good practice to have the same naming conventions for both of the packages (for the test cases and the source classes)? If not, what would be a better approach?

Improve this question
6
  • 1
    No idea if it's good practice, but it's a popular one. The other option (to put "Test" into the package name, method names etc) smacks a bit too much of "Smurf naming". As you say, it's hard to think of case where being unable to "distinguish between "test" and "to-test" if only provided with the package name" would be a problem.
    – David Arno
    Aug 19, 2016 at 10:15
  • @DavidArno Thanks for your input :) How to avoid smurf-naming then? I mean we would end up with com.hello.world.test.helloWorld.java, wouldn't we?
    – OddDev
    Aug 19, 2016 at 11:24
  • The "smurf" problem is more when you have a method XXXTest() in com.hello.world.test.helloWorldTest.java. General advise would be to only have "Test" appear once in the path, so either (a) use test in the package name (and name the test file the same as the file under test) or (b) make the package name the same and add "test" to the file/class name.
    – David Arno
    Aug 19, 2016 at 11:27
  • @DavidArno Ah, thanks for clarification! I got your first comment wrong. I got it now.
    – OddDev
    Aug 19, 2016 at 11:28
  • Well I'd argue that, if it was unclear, I got my first comment wrong :)
    – David Arno
    Aug 19, 2016 at 11:31

1 Answer 1

Reset to default
16

That is a good convention.

Sometimes you want to write unit tests for package-private classes and methods also. You won't be able to call them from a unit test class placed in another package.

There shouldn't be any confusion about having unit test classes in the same namespace as they shouldn't be in the class path when compiling or running the production code.

Here's an example of a small module with a public interface, a public factory class and two package-private implementation classes:

src/main/java:
    com.hello.transmogrifier
        public interface Transmogrifier
        public class TransmogrifierFactory
        class MapTransmogrifier implements Transmogrifier
        class ListTransmogrifier implements Transmogrifier

scr/test/java:
    com.hello.transmogrifier
        public class TransmogrifierFactoryTest
        public class MapTransmogrifierTest
        public class ListTransmogrifierTest

Hiding the implementations of the Transmogrifier interface could be a valid design choice. Perhaps it's the responsibility of the factory class to choose the implementation.

Since the implementations are package-private, you need to place the unit test classes in the same package if you wish to test them directly. If you have your unit test classes in some other package, you only have direct access to the public interface and the factory class from your tests.

Improve this answer
11
  • 2
    "Usually you want to write unit tests for package-private classes and methods also". No! This is really bad practice. Package private types are implementation details and should never be tested directly. Only test public APIs.
    – David Arno
    Aug 19, 2016 at 13:18
  • 1
    @DavidArno I disagree. However, I replaced the word "usually" with the word "sometimes" to avoid that particular discussion.
    – COME FROM
    Aug 19, 2016 at 13:20
  • 2
    You may disagree all you want, but testing the inner workings of a piece of code leads both to tight coupling between those inner workings and the tests and to brittle tests that readily break during even simple refactoring. It is very bad practice.
    – David Arno
    Aug 19, 2016 at 13:35
  • If I want to make sure all my Transmogrifier implementations work, no matter what the factory does, then I'm going to write unit tests that test each implementation. Note that the implementations have a shared public API even though the classes are package-private. These test should not break unless I change the public API. Actually, I'd probably write a generic test for a Transmogrifier and then run it against each implementation. While it's possible to get each implementation using the factory, it's better to not have that dependency when testing Transmogrifiers.
    – COME FROM
    Aug 19, 2016 at 13:45
  • Then one day, you look at MapTransmogrifier and ListTransmogrifier and decide they could be made into one class, so you create ListMapTransmogrifier, modify the factory to use that and delete the two classes. The code now doesn't compile, so you have to modify every test in both MapTransmogrifierTest and ListTransmogrifierTest to get it compiling. A test fails. Was that due to changing the tests or creating ListMapTransmogrifier? Out comes the debugger to find out ... alternatively when the tests use the factory, you do that refactor and all still compiles...
    – David Arno
    Aug 19, 2016 at 14:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.