我想对测试方法有一些看法。
让我们假设我们有A类和B类.B类使用A类的功能.B类经过全面测试,因此一些测试覆盖也间接应用于A类。
我应该直接为A级写完整的测试吗?或者我应该只测试未测试的A类功能吗?
我在问,因为将来可能会删除或修改B类,因为它可能不会使用A类中的相同功能,因此可能会留下一些未经测试的方法。你会做什么?
答案 0 :(得分:8)
是的,你应该全面测试A
。
B
可能会在某个时刻发生变化,因为它现在使用A
并不意味着它总会如此。
B
可能无法使用A
的所有功能,这意味着您没有测试所有代码。
答案 1 :(得分:8)
IMO,您应该在不基于B
已经过测试的事实的情况下测试A
的行为。
实际上,有三种情况:
A
和B
属于同一层:
如果A
是通过B
的重构周期(提取类)创建的(通常在练习一个好的TDD时发生),那么A
应该完全没有经过测试!根本不需要测试!
实际上,代码结构(在这种情况下,类/ SRP的分离)应该独立于 Unit 概念;在这种情况下,B
和A
属于同一单位。
如果A
存在之前 B
,则B
不应基于此事实,B
的整个行为应该进行测试。
A
和B
不属于同一层(例如,不同的boundaries):
B
是一个GUI类,A
是一个商务类,那么在测试A
和B
时应该加倍/模拟A
应该有专门的测试。behavior/feature
概念混合在一起。要了解原因,请阅读Bob最近关于这个概念的文章:
摘录:
一种常见的误解是测试的设计必须反映出来 生产代码的设计。作为作者,TDD不要求 建议,“系统中的每个单元都与一个 精心设计的单元测试。“的确,这是其中一个原因 我们中的许多人已经停止称他们为“单位”测试。
注意:TDD并不关心“未来”,相反,它可以帮助您编写尽可能多的代码,而不是更多。所以你不应该担心这个:
将来B类将有可能成为 删除或修改
如果您编写了良好的测试(我更喜欢“specs”一词),则会立即检测到此类删除。
答案 2 :(得分:5)
肯定为A级写完整的测试。你在这里回答了你自己的问题:
(...)maybe in the future there will be possibility that the B class will be removed or modified in the way that it might not use the same functionality from A class so it might leave some methods untested.
答案 3 :(得分:5)
单元测试背后的一般思想是每个单元由一个工作单元组成。这可以像方法一样小,也可以像几种方法一样大。
您已经涵盖了B依赖于A的场景,但是从您的故事中我们可以假设A也将单独使用。因此,A也应该进行测试,因为它是一个单独的工作单元。
答案 4 :(得分:4)
B应该只通过接口IA使用A
通过它的公共界面测试B,通过它的公共界面测试A.
两者都应该进行测试。
答案 5 :(得分:3)
我认为你的答案就在那里:
in the future there will be possibility that the B class will be removed or modified
我认为对于A的测试套件来说这是一个很好的例子。
答案 6 :(得分:3)
你应该首先测试A,然后 B.如果你在B上遇到测试失败,你就没有足够的诊断来知道它是否来自B的代码或在A的。
单元测试不只是“通过/失败”,它们非常关于诊断问题。