我的问题是,虽然我确信相信单元测试的价值(这个项目实际上是TDD,但并不是真正的问题),我想知道有关经验单元测试问题的更多编码和维护(即测试本身).再次.在我看来,毫无疑问,这个特定的项目比单元测试更好,没有它,我也关心测试的长期可维护性.
有一些我使用的技术,遵循他人的建议来帮助解决这个问题.一般来说,
>
我们创建了一个“依赖”vs“独立”桶中的测试列表.独立测试不需要任何不在源代码管理中的任何内容.所以对我们的数据访问层的任何调用都是嘲笑或从xml文件获取数据,而不是真正的数据库.作为名称建议的依赖测试取决于运行测试时可能未正确配置/可用的配置文件或数据库或网络的东西.将测试分成这样的组件已经非常有价值,允许我们为早期开发和独立任务关键测试编写依赖的“丢弃”测试,可以依赖和重新测试腐败.它也使CI服务器易于管理,因为它不必在db / db连接等上进行设置和维护.
>
我们针对不同级别的代码.例如,我们测试了“main”,并测试了“main”将调用的所有方法.这使我们有能力瞄准系统的细节和总体目标.如果“主要”测试发生故障,那么“主要”测试很难调试,但它们通常不是唯一的破坏(详细测试也会中断).仔细阅读详细的测试和调试方法比较容易,但如果它们破坏了,但是它们不足以知道重构器是否会杀死系统(这是“主要测试”).
>
感觉舒适的“主要”测试对于重构器并没有代码库来说至关重要.所以’main’测试就像许多测试一样,使用不同的args来映射到用例的方法.它基本上是最高级别的代码的入口点,因此可能不是真正的“单元”测试.然而,我发现我真的需要更高级别的测试,以便感觉到重构器没有炸毁代码库.较低级别的测试(真正是“工作单位”)是不够的.
所有这一切都得到了解.随着项目向前发展,我发现我需要对代码库实施更改(有时相当重要,有时是微不足道的),我发现当更改导致测试失败时,测试失败和实际退化业务逻辑故障与单元之间存在比例测试无效换句话说,有时测试失败是因为实际代码库中的回归错误,有时是因为单元测试断言不再有效,而是需要更改的断言.似乎大致上,当测试失败时,对于这个特定的项目,它已经在大约甚至(50％).
有没有人跟踪他们的项目的这个比例,如果是这样,你有什么知识(如果有的话)这个比例？我不知道它甚至表示任何东西,但是我注意到大约一半的时间,测试失败导致我调整测试断言,而不是真正修复真正的代码库中的回归错误.无论何时发生这种情况,都让我觉得我只是浪费了我的一天x我想知道我的测试方法是否可以更有效率.解决测试断言通常比实际的回归错误需要更长的时间,这些错误既反对又令人沮丧.
编辑
请注意,这个问题是关于探索这个比例意味着什么以及你对这个比例的看法.什么时候“臭”？
I have noticed that about half the time that test failures lead me to adjusting test asserts rather than actually fixing regression bugs in the real codebase.
当测试失败时,有三个选项：
>实施被破坏,应该是固定的,
>测试被破坏,应该固定,或
>测试不再需要了(因为需求变化),应该被删除.
正确识别这三个选项中的哪一个是很重要的.我写我的测试的方式,我以测试的名义记录测试指定/测试的行为,这样当测试失败时,我会很容易地找出为什么测试最初写的.我在这里写了更多的内容：http://blog.orfjackal.net/2010/02/three-styles-of-naming-tests.html
在你的情况下
>如果您需要更改测试,因为需求变化,并且一次只需要进行一些测试,那么一切都是正常的(测试很好的是isolated,所以每个行为仅由一个测试指定) .
>如果您需要更改测试,因为需要更改,许多测试一次需要更改,那么这是一个test smell,您有很多测试测试相同的事情(测试没有很好的隔离).测试可能正在测试more than one interesting behaviour.解决方案是编写更集中的测试和更好的解耦代码.
>如果测试需要在重构时进行更改,那么测试的结果与实现细节太紧密相关.尝试编写以系统行为为中心的测试,而不是实现. The article我先前提到的应该给你一些想法.
(有趣的一点是,如果您发现自己大多是重写类,而不是更改它们,则当需求发生变化时,可能表示该代码遵循SRP,OCP及其他设计原则).
