编写单元测试（java）的最佳位置？

Question

What is the difference between writing a unit test in the same class as the tested method or writing it in another class (of the same package or extern package)? What are the advantages or disadvantages of these test-locations?

Answer 1

If you have your tests in separate class(es), you can

• use a well known unit testing framework which makes your life way easier - all the ones I know assume that you keep your tests separated from the tested code
• have as many test cases as you like (without making your production class huge and hard to manage - note that in a well managed project, there is about as much unit test code as production code, and probably a lot more public test methods than production API methods, which may eventually drive the API indexer of your IDE, and subsequently yourself, crazy...)
• ship your production code without tests - including your test dependencies too (noone likes to bundle a ton of 3rd party stuff used only for testing into the product deployment bundle, right?)
• change tests without touching the production code itself (this will make auditing and change control in your SCM a lot easier, as it will always be trivial to separate changes in production code/data from changes in tests)

Answer 2

The best practice is separate tests from the code they are validating. The reason is simple: you do not want to package tests with your application. Application should be clean. Tests should validate functionality from outside.

Tests often have additional dependencies (eg testing framework, mockup library etc).

Common practice is to put source code under src/main/java and tests under src/tests/java .

Answer 3

Advantages of writing in separated classes is that you can separate your tests from your code. For example with maven :
1. Build everything
2. Executes the classes including the **/*Test*.java pattern

I don't even know how you can unit test in the same class than your code...

Answer 4

Test methods are there to test your code. Putting them in the tested class clutters the API of the class, and makes the bytecode and dependencies of the class larger than necessary.

If I want to use your Calculator class, I don't need the testPlusWorks() and testMinusWorks() test methods. I just need plus() and minus() . And if testPlusWorks depends on some class from the JUnit or Mockito library, I don't want these dependencies in the production environment: they're only useful when testing the class.

Answer 5

There is not "right" answer for this question.

Writing in the same class: Allows you to test private methods but mess up the code.

Writing in the same project: Allows you to test internal methods/logics but mess up the project and extends your compilation time.

Writing externally: Prevents you from testing project internal methods/classes but keeps the tests clean and external to your "production" coder.

Answer 6

I find it best to write unit tests in a different source folder altogether, but keep them in the same package as you can still access packaged(default) scoped methods and varialble.

1. This keeps your tests together for ease of navigation and sanity and
2. When you do a build, you can exclude the test classes in the jar/war/ear.