Java 我应该把我的 JUnit 测试放在哪里?
声明:本页面是StackOverFlow热门问题的中英对照翻译,遵循CC BY-SA 4.0协议,如果您需要使用它,必须同样遵循CC BY-SA许可,注明原文地址和作者信息,同时你必须将它归于原作者(不是我):StackOverFlow
原文地址: http://stackoverflow.com/questions/811827/
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
Where should I put my JUnit tests?
提问by Jakub Arnold
I've got 2 questions about organising Unit tests.
我有 2 个关于组织单元测试的问题。
Do I have to put test to the same package as tested class, or can I organise tests in different packages?
For example if I have validityand othertests, is it correct to split them into different packages, even if they are for same class?
What about mock and stub classes? Shall I separate them from packages containing only tests, or put them together?
我是否必须将测试放在与测试类相同的包中,还是可以在不同的包中组织测试?
例如,如果我有有效性和其他测试,将它们分成不同的包是否正确,即使它们是同一班级的?
模拟和存根类呢?我应该将它们与仅包含测试的包分开,还是将它们放在一起?
采纳答案by Paul Kuykendall
The way we do our JUnit test cases is to put them in the same package, but in a different root directory. Since we use Maven, we just use the standard locations making the structure similar to the following.
我们执行 JUnit 测试用例的方式是将它们放在同一个包中,但放在不同的根目录中。由于我们使用 Maven,我们只使用标准位置,使结构类似于以下内容。
src/main/java/com/foo/Bar.java
src/test/java/com/foo/BarTest.java
Obviously there's more to the structure, but this lets us build the tests separately from the mainline code, but still access protected classes and the like. With respect to different types of tests, this is very subjective. When we started our testing effort (which unfortunately started after development), I tried to keep things pretty isolated. Unfortunately, it quickly became a nightmare when we got to the 500+ test case point. I've since tried to do more consolidation. This led to reduced amounts of code to maintain. As I said, though, it's very subjective.
显然,结构还有更多内容,但这让我们可以与主线代码分开构建测试,但仍然可以访问受保护的类等。对于不同类型的测试,这是非常主观的。当我们开始我们的测试工作(不幸的是在开发之后开始)时,我试图让事情变得非常孤立。不幸的是,当我们到达 500 多个测试用例点时,它很快就变成了一场噩梦。从那以后,我尝试进行更多的整合。这导致需要维护的代码量减少。不过,正如我所说,这是非常主观的。
As far as test-only code, we keep it in a separate com.foo.test
package that resides only in the src/test/java
tree.
至于仅测试代码,我们将其保存在com.foo.test
仅驻留在src/test/java
树中的单独包中。
回答by Dima
Test classes should be rather in different packages, it's easier to separate them from the production code when you package it for release. I usually keep lots of test fluff in those packages, all sorts of mocks, configurations, scenarios.. But when you build - it doesn't get it. In some situations, it's a good idea to keep your testing stuff even in different projects. Depends.
测试类应该在不同的包中,当您打包发布时,更容易将它们与生产代码分开。我通常会在这些包中保留大量测试内容,各种模拟、配置、场景......但是当你构建时 - 它没有得到它。在某些情况下,即使在不同的项目中也保留您的测试内容是个好主意。要看。
回答by Yishai
Keeping it the same package allows you to use package-private visibility for code that is intended to be accessed via the test only.
保持相同的包允许您对旨在仅通过测试访问的代码使用包私有可见性。
Regarding using separate root directories, that is a good practice. It also has an advantage for us, since we use IDEA, IDEA recognizes that production code cannot reference test code.
关于使用单独的根目录,这是一个很好的做法。这对我们来说也有一个优势,因为我们使用 IDEA,IDEA 认识到生产代码不能引用测试代码。
In terms of keeping them separate, there is a great power in having one, and only one, test class per production class at the unit level. Of course, some classes get created in production as part of refactoring that have no test classes at all, and that is fine, but when you want to know what test tests a certain class, having a convention that says ClassNameTest is the tests for ClassName is very helpful.
就将它们分开而言,在单元级别为每个生产类设置一个且只有一个测试类具有强大的功能。当然,有些类是在生产中作为重构的一部分创建的,它们根本没有测试类,这很好,但是当你想知道什么测试测试某个类时,有一个约定,说 ClassNameTest 是 ClassName 的测试非常有帮助。
TestNG is much friendlier to this paradigm than JUnit, though.
不过,TestNG 比 JUnit 对这种范式更友好。
回答by Kathy Van Stone
I too tend to put my tests in the same package but under a different root directory. This allows me to test package-private classes or access packing-private classes while testing something else in the package. They are kept in a separate directory tree to allow excluding them from the deployed result (in particular to ensure that test code didn't accidentally get into production code). What matters most, however, is what works for your situation.
我也倾向于将我的测试放在同一个包中,但放在不同的根目录下。这允许我在测试包中的其他内容时测试包私有类或访问打包私有类。它们保存在单独的目录树中,以允许将它们从部署结果中排除(特别是确保测试代码不会意外进入生产代码)。然而,最重要的是什么适合你的情况。
In terms of how many test classes per production class, the theory I've seen is that you write one test class per fixture, that is per setup structure. In many cases that is the same (or close enough) to one test class per production class, but I have sometimes written more test classes (in particular equality tests tend to be separated) for a give production class, and occasionally one test class of for a group of (related) production classes (say, for testing the Strategy pattern).
就每个生产类有多少测试类而言,我所看到的理论是您为每个夹具编写一个测试类,即每个设置结构。在许多情况下,每个生产类与一个测试类相同(或足够接近),但我有时会为给定的生产类编写更多测试类(特别是平等测试往往是分开的),偶尔还有一个测试类对于一组(相关)生产类(例如,用于测试策略模式)。
Mostly, I don't worry too much about the theory, but rework the tests as needed to keep duplication to an absolute minimum.
大多数情况下,我不太担心理论,但会根据需要重新进行测试以将重复保持在绝对最低限度。