3 changed wording
source | link

That is a good convention.

UsuallySometimes 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.

That is a good convention.

Usually 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.

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.

2 added an example
source | link

That is a good convention.

Usually 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.

That is a good convention.

Usually 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.

That is a good convention.

Usually 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.

1
source | link

That is a good convention.

Usually 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.