单元测试:在设置方法中使用断言是一种好习惯吗? [英] Unit testing: Is it a good practice to have assertions in setup methods?

查看:152
本文介绍了单元测试:在设置方法中使用断言是一种好习惯吗?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

在单元测试中,设置方法用于创建测试所需的对象.

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.

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.

但是,带有声明的设置"和 单元测试调用其他单元测试.

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?

答案是:一般来说,这不是一个好习惯.如果需要测试设置结果,建议添加带有断言的单独测试方法(我勾选的答案);要记录意图,请考虑使用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).

我看到了几个优点:

  • 设置简短易懂,以提高可读性.
  • 断言仅运行一次,这更有效.
  • 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:

  1. 一些测试本地代码的测试,
  2. 以及一些称为更多全局代码的测试,这些代码间接调用与先前测试相同的代码.

当您都读取失败的测试结果时,您已经必须照顾这个不在测试中,而在被调用的代码中的依赖性.您必须先修复简单测试,然后重新运行全局测试以查看其是否仍然失败. 这就是为什么我不被前面解释的隐式依赖所困扰的原因.

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屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆