单元测试:在设置方法中使用断言是一个好习惯吗? [英] Unit testing: Is it a good practice to have assertions in setup methods?
问题描述
在单元测试中，setup 方法用于创建测试所需的对象.
In unit testing, the setup method is used to create the objects needed for testing.
在那些设置方法中，我喜欢使用断言:我知道我想在那些中看到什么值对象，我喜欢通过断言来记录这些知识.
In those setup methods, I like using assertions: I know what values I want to see in those objects, and I like to document that knowledge via an assertion.
在最近关于 单元测试调用其他单元测试在stackoverflow上，总体感觉似乎是单元测试不应该调用其他测试:这个问题的答案似乎是你应该重构你的设置，所以测试用例不相互依赖.
In a recent post on unit tests calling other unit tests here on stackoverflow, the general feeling seems to be that unit tests should not call other tests: The answer to that question seems to be that you should refactor your setup, so that test cases do not depend on each other.
但是setup-with-asserts"和单元测试调用其他单元测试.
But there isn't much difference in a "setup-with-asserts" and a unit test calling other unit tests.
因此我的问题是:在设置方法中使用断言是一种好习惯吗?
Hence my question: Is it good practice to have assertions in setup methods?
结果是:这通常不是一个好的做法.如果需要测试setup结果，建议在assertions中添加单独的测试方法(我勾选的答案)；要记录意图，请考虑使用 Java 断言.
The answer turns out to be: this is not a good practice in general. If the setup results need to be tested, it is recommended to add a separate test method with the assertions (the answer I ticked); for documenting intent, consider using Java asserts.
推荐答案
代替设置中的断言来检查结果，我使用了一个简单的测试(与其他测试方法一样，但定位作为第一种测试方法).
Instead of assertions in the setup to check the result, I used a simple test (a test method along the others, but positionned as first test method).
我已经看到了几个优点:
I have seen several advantages:
- 设置保持简短且重点突出，以提高可读性.
- 断言只运行一次，这样效率更高.
- The setup keeps short and focused, for readability.
- The assertions are run only once, which is more efficient.
使用和讨论:
例如，我将方法命名为 testSetup().
For example, I name the method testSetup().
为了使用它，当我在那个类中有一些测试错误时，我知道如果 testSetup() 有错误，我不需要打扰其他错误，我需要先修复这个.
To use it, when I have some test errors in that class, I know that if testSetup() has an error, I don't need to bother with the other errors, I need to fix this one first.
如果有人对此感到困扰，并希望明确此依赖项，则可以在 setup() 方法中调用 testSetup().但我认为这不重要.我的观点是，在 JUnit 中，您已经可以在其余测试中使用类似的东西:
If someone is bothered by this, and wants to make this dependency explicit, the testSetup() could be called in the setup() method. But I don't think it matters. My point is that, in JUnit, you can already have something similar in the rest of your tests:
- 一些测试本地代码的测试，
- 以及一些调用更多全局代码的测试，它们间接调用了与之前的测试相同的代码.
当您读取两个都失败的测试结果时，您已经必须处理这个不在测试中，而是在被调用的代码中的依赖项.您必须先修复简单测试，然后重新运行全局测试，看看它是否仍然失败.这就是为什么我不会被我之前解释过的隐式依赖所困扰的原因.
When you read the test result where both fail, you already have to take care of this dependency that is not in the test, but in the code being called. You have to fix the simple test first, and then rerun the global test to see if it still fails. This is the reason why I'm not bothered by the implicit dependency I explained before.
这篇关于单元测试:在设置方法中使用断言是一个好习惯吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
