为什么jUnit的fixtureSetup必须是静态的?
我用 jUnit 的 @BeforeClass 注释标记了一个方法,并收到此异常,表明它必须是静态的。 理由是什么? 这迫使我的所有 init 都处于静态字段中,据我所知,这没有什么充分的理由。
在.Net (NUnit) 中,情况并非如此。
编辑 - 用 @BeforeClass 注释的方法仅运行一次这一事实与它是静态方法无关 - 人们可以让非静态方法仅运行一次(如在 NUnit 中)。
I marked a method with jUnit's @BeforeClass annotation, and got this exception saying it must be static. What's the rationale? This forces all my init to be on static fields, for no good reason as far as I see.
In .Net (NUnit), this is not the case.
Edit - the fact that a method annotated with @BeforeClass runs only once has nothing to do with it being a static method - one can have a non-static method run only once (as in NUnit).
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(8)
JUnit总是为每个@Test 方法创建一个测试类实例。 这是一个基本的设计决策,可以更轻松地编写测试而不会产生副作用。 好的测试没有任何运行顺序依赖性(请参阅FIRST)并且为每个测试创建测试类的新实例及其实例变量对于实现此目标至关重要。 一些测试框架对所有测试重用相同的测试类实例,这导致在测试之间意外产生副作用的可能性更大。
而且因为每个测试方法都有自己的实例,所以 @BeforeClass/@AfterClass 方法作为实例方法是没有意义的。 否则,应该在哪个测试类实例上调用这些方法? 如果 @BeforeClass/@AfterClass 方法可以引用实例变量,那么只有一个 @Test 方法可以访问这些相同的实例变量 - 其余方法的实例变量将位于它们的默认值 - 并且 @Test 方法将被随机选择,因为 .class 文件中方法的顺序未指定/依赖于编译器(IIRC,Java 的反射 API 以与 .class 文件中声明的顺序相同的顺序返回方法)。类文件,尽管该行为也未指定 - 我已经编写了 一个库 来实际按行号对它们进行排序)。
因此,强制这些方法为静态是唯一合理的解决方案。
下面是一个示例:
Which prints:
如您所见,每个测试都是使用其自己的实例执行的。 JUnit 所做的事情基本上与此相同:
JUnit always creates one instance of the test class for each @Test method. This is a fundamental design decision to make it easier to write tests without side-effects. Good tests do not have any order-of-run dependencies (see F.I.R.S.T) and creating fresh instances of the test class and its instance variables for each test is crucial in achieving this. Some testing frameworks reuse the same test class instance for all tests, which leads to more possibilities of accidentally creating side-effects between tests.
And because each test method has its own instance, it makes no sense for the @BeforeClass/@AfterClass methods to be instance methods. Otherwise, on which of the test class instances should the methods be called? If it would be possible for the @BeforeClass/@AfterClass methods to reference instance variables, then only one of the @Test methods would have access to those same instance variables - the rest would have the instance variables at their default values - and the @Test method would be randomly selected, because the order of methods in the .class file is unspecified/compiler-dependent (IIRC, Java's reflection API returns the methods in the same order as they are declared in the .class file, although also that behaviour is unspecified - I have written a library for actually sorting them by their line numbers).
So enforcing those methods to be static is the only reasonable solution.
Here is an example:
Which prints:
As you can see, each of the tests is executed with its own instance. What JUnit does is basically the same as this:
简短的答案是:没有充分的理由将其设为静态。
事实上,如果您使用 Junit 执行基于 DBUnit 的 DAO 集成测试,则将其设为静态会导致各种问题。 静态要求会干扰依赖项注入、应用程序上下文访问、资源处理、日志记录以及任何依赖于“getClass”的内容。
The short answer is this: there is no good reason for it to be static.
In fact, making it static causes all sorts of problems if you use Junit to execute DBUnit based DAO integration tests. The static requirement interferes with dependency injection, application context access, resource handling, logging, and anything that depends on "getClass".
JUnit 文档似乎很少,但我猜测:也许 JUnit 在运行每个测试用例之前创建了一个测试类的新实例,因此在运行中保持“固定”状态的唯一方法是使其成为静态的,这可以通过确保你的fixtureSetup(@BeforeClass方法)是静态的来强制执行。
JUnit documentation seems scarce, but I'll guess: perhaps JUnit creates a new instance of your test class before running each test case, so the only way for your "fixture" state to persist across runs is to have it be static, which can be enforced by making sure your fixtureSetup (@BeforeClass method) is static.
JUnit 似乎为每个测试方法创建了一个新的测试类实例。 试试这段代码
输出是
0
0
0
这意味着如果 @BeforeClass 方法不是静态的,那么它必须在每个测试方法之前执行,并且无法区分 @Before 和 @BeforeClass 的语义
It seems that JUnit creates a new instance of the test class for each test method. Try this code out
The output is
0
0
0
This means that if the @BeforeClass method is not static then it will have to be executed before each test method and there would be no way to differentiate between the semantics of @Before and @BeforeClass
尽管这不能回答原来的问题。 它将回答明显的后续问题。 如何创建在课堂之前和之后以及测试之前和之后有效的规则。
要实现这一点,您可以使用以下模式:
在 before(Class) 上,JPAConnection 创建连接,在 after(Class) 上创建连接,然后将其关闭。
getEntityManger
返回一个JPAConnection
的内部类,它实现了jpa 的EntityManager,并且可以访问jpaConnection
内部的连接。 在之前(测试)它开始一个事务,在之后(测试)它再次回滚它。这不是线程安全的,但可以使其成为线程安全的。
JPAConnection.class
的选定代码Though this won't answer the original question. It will answers the obvious follow up. How to create a rule that works before and after a class and before and after a test.
To achieve that you can use this pattern:
On before(Class) the JPAConnection creates the connection once on after(Class) it closes it.
getEntityManger
returns an inner class ofJPAConnection
that implements jpa's EntityManager and can access the connection inside thejpaConnection
. On before (test) it begins a transaction on after (test) it rolls it back again.This isn't thread-safe but can be made to be so.
Selected code of
JPAConnection.class
有两种类型的注释:
因此 @BeforeClass 必须声明为静态因为它被调用一次。 您还应该考虑静态是确保测试之间正确“状态”传播的唯一方法(JUnit 模型为每个 @Test 强加一个测试实例),并且,因为在 Java 中只有静态方法可以访问静态数据... @BeforeClass 和 @ AfterClass 只能应用于静态方法。
此示例测试应阐明 @BeforeClass 与 @Before 的用法:
输出:
there are two types of annotations:
so @BeforeClass must be declared static because it is called once. You should also consider that being static is the only way to ensure proper "state" propagation between tests (JUnit model imposes one test instance per @Test) and, since in Java only static methods can access static data... @BeforeClass and @AfterClass can be applied only to static methods.
This example test should clarify @BeforeClass vs @Before usage:
output:
根据 JUnit 5,严格为每个测试方法创建一个新实例的理念似乎有所放松。 他们添加了注释这只会实例化一个测试类一次。 因此,此注释还允许使用 @BeforeAll/@AfterAll (@BeforeClass/@AfterClass 的替换)注释的方法是非静态的。 因此,像这样的测试类:
将打印:
因此,您实际上可以为每个测试类实例化一次对象。 当然,这确实使您有责任避免改变以这种方式实例化的对象。
As per JUnit 5, it seems the philosophy on strictly creating a new instance per test method has been somewhat loosened. They have added an annotation that will instantiate a test class only once. This annotation therefore also allows methods annotated with @BeforeAll/@AfterAll (the replacements to @BeforeClass/@AfterClass) to be non-static. So, a test class like this:
would print:
So, you can actually instantiate objects once per test class. Of course, this does make it your own responsibility to avoid mutating objects that are instantiated this way.
要解决此问题,只需将该方法更改
为
并将该方法中定义的所有内容更改为
static
。To resolve this issue just change the method
to
and all that are defined in this method to
static
.