Java Eclipse junit 在同一个项目中测试
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/3573842/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Eclipse junit testing in the same project
提问by david99world
This is a relatively open question. If I have built an application in a project in Eclipse and I then want to test this project, should I create the JUnit code within the same project or create a separate project. For instance...
这是一个相对开放的问题。如果我已经在 Eclipse 的一个项目中构建了一个应用程序，然后我想测试这个项目，我应该在同一个项目中创建 JUnit 代码还是创建一个单独的项目。例如...
ShopSystemmaybe the name of my main project - should I create a project called say, ShopSystemTest?
ShopSystem也许是我的主要项目的名称 - 我应该创建一个名为 say 的项目ShopSystemTest吗？
In general - how far "away" should the testing code be stored from the main project folder? If I store the testing code within the main project and then export the main project as a runnable jar it will take the testing code with it, which isn't ideal...
一般来说 - 测试代码应该与主项目文件夹“相距”多远？如果我将测试代码存储在主项目中，然后将主项目导出为一个可运行的 jar，它将携带测试代码，这并不理想......
Suggestions?
建议？
采纳答案by Henning
While there is no only right way, the usual approach is to keep unit tests in the same project.
虽然没有唯一正确的方法，但通常的方法是将单元测试保留在同一个项目中。
You can create a second source folder (like test), where you put your test classes into the same packages as the classes under test. This also allows you to test package-private classes while not flooding your main source packages with test classes.
您可以创建第二个源文件夹（如test），将您的测试类放入与被测类相同的包中。这也允许您测试包私有类，同时不会用测试类淹没您的主要源包。
Your source folder/package structure would then look like this:
您的源文件夹/包结构将如下所示：
-sources
-main
-my.package
-MyClass.java
-test
-my.package
-MyClassTest.java
You can then configure your build to not include the testsource folder when packing the JAR.
然后，您可以将构建配置为test在打包 JAR 时不包含源文件夹。
回答by fastcodejava
Typically you have -
通常你有 -
/src/main/java (for codes)
/src/test/java (for tests)
回答by Riduidel
Consider the maven way : In a maven project, soruces are organized this way
考虑maven方式：在maven项目中，源是这样组织的
src
|--main
| |--java
|--test
|--java
Your source code goes in src/main/java, your junit test code goes in src/test/java, they both are source folder (and as a consequence you can put your jUnit code in the same package as your Java code, but in a different source folder).
您的源代码在 src/main/java 中，您的 junit 测试代码在 src/test/java 中，它们都是源文件夹（因此您可以将 jUnit 代码与 Java 代码放在同一个包中，但在不同的源文件夹）。
The interest is that for usual coding, your jUnit classes are in code packages, but on jar creation, you can take classes coming only from src/main/java and not release your tests.
有趣的是，对于通常的编码，您的 jUnit 类位于代码包中，但是在创建 jar 时，您可以使用仅来自 src/main/java 的类，而不是发布您的测试。
回答by Sean Patrick Floyd
I like the maven convention a lot: There is a separate source tree for main and test in the same project, main code gets deployed, test code doesn't. Package structures can be (but don't have to be) identical.
我非常喜欢 maven 约定：在同一个项目中有一个单独的 main 和 test 源代码树，主要代码被部署，测试代码没有。包结构可以（但不必）相同。
project
src
main
java // source files
resources // xml, properties etc
test
java // source files
resources // xml, properties etc
And in eclipse, when you choose new -> JUnit test case, you just change the source folder to src/test/java and leave the suggested package as is.
在 Eclipse 中，当您选择 时new -> JUnit test case，您只需将源文件夹更改为 src/test/java 并保留建议的包。
(One of the benefits of remaining in the same package is having access to protected and package scoped members, although this is not 'proper' unit test behavior)
（留在同一个包中的好处之一是可以访问受保护和包范围的成员，尽管这不是“正确的”单元测试行为）
Update:Here's some code to illustrate my last point:
更新：这里有一些代码来说明我的最后一点：
Main class (in src/main/java):
主类（在 src/main/java 中）：
package com.test;
public class Foo{
static class Phleem{
public Phleem(final String stupidParameter){
}
}
String bar;
protected String baz;
protected Object thingy;
}
Test class (in src/test/java):
测试类（在 src/test/java 中）：
package com.test;
import org.junit.Test;
public class FooTest{
@Test
public void testFoo(){
final Foo foo = new Foo();
foo.bar = "I can access default-scoped members";
foo.baz = "And protected members, too";
foo.thingy = new Foo.Phleem("And I can access default-scoped classes");
}
}
