ava*_*sen 31 refactoring unit-testing fixtures assertions
在单元测试中,setup方法用于创建测试所需的对象.
在那些设置方法中,我喜欢使用断言:我知道我想在这些对象中看到什么值,我喜欢通过断言来记录这些知识.
在最近的文章中对单元测试调用其他单元测试在这里计算器,总的感觉似乎是,单元测试应该没有调用其他检查:这个问题的答案似乎是,你应该重构你的设置,使测试用例做不相互依赖.
但是"设置与断言"和单元测试调用其他单元测试没有太大区别.
因此我的问题是:在设置方法中使用断言是一种好习惯吗？
编辑:
答案结果证明:这不是一般的好习惯.如果需要测试设置结果,建议在断言中添加单独的测试方法(我勾选的答案); 为了记录意图,请考虑使用Java断言.
KLE*_*KLE 15
我没有使用设置中的断言来检查结果,而是使用了一个简单的测试(沿着其他测试方法,但定位为第一个测试方法).
我看到了几个优点:
用法和讨论 :
例如,我将方法命名为testSetup().
要使用它,当我在该类中有一些测试错误时,我知道如果testSetup()有错误,我不需要打扰其他错误,我需要先解决这个问题.
如果有人对此感到困扰,并且希望显式地使用此依赖项,则可以在setup()方法中调用testSetup().但我认为这不重要.我的观点是,在JUnit中,您可以在其余测试中获得类似的东西:
当您读取两个都失败的测试结果时,您必须处理不在测试中但在被调用的代码中的此依赖项.您必须先修复简单测试,然后重新运行全局测试以查看它是否仍然失败.这就是为什么我不会被我之前解释过的隐含依赖所困扰的原因.
他们是不同的场景; 我没有看到相似之处.
安装方法应包含(理想情况下)夹具中所有测试的通用代码.因此,如果在执行其余测试代码之前某些事情必须为真,则将断言置于测试设置方法中并没有任何内在错误.设置是测试的扩展; 它是整个测试的一部分.如果断言跳闸,人们将发现哪个先决条件失败.
另一方面,如果设置足够复杂,您觉得需要断言它是正确的,那么它可能是一个警告标志.此外,如果所有测试都不需要设置的完整输出,则表明夹具具有较差的内聚力,应根据场景和/或重构进行拆分.
部分原因是我倾向于远离使用安装方法.在可能的情况下,我使用私人工厂方法或类似设置.它使测试更具可读性并避免混淆.有时候这是不实际的(例如使用紧密耦合的类和/或编写集成测试时),但对于我的大多数测试,它都可以完成这项工作.
在Setup/TearDown方法中使用断言是不可取的.如果用户需要"理解"某些测试逻辑不在测试方法中,则会使测试的可读性降低.有些时候你没有选择,只能将setup/teardown方法用于其他目的之外的东西.
在这个问题中存在一个更大的问题:一个调用另一个测试的测试,它是测试中某些问题的气味.每个测试都应测试代码的特定方面,并且其中只应包含一个或两个断言,因此如果您的测试调用另一个测试,则可能在该测试中测试了太多内容.欲了解更多信息,请阅读:单元测试:一次测试,一次断言 - 为什么会起作用