我发现关于TDD的事情是它需要时间来设置你的测试并且自然是懒惰的我总是想写尽可能少的代码.我似乎做的第一件事是测试我的构造函数已经设置了所有的属性,但这是否有点过分？
我的问题是你在单元测试中写出了什么级别的粒度？
..是否有一个测试太多的情况？
我得到的代码是有效的,而不是测试,因此我的理念是尽可能少地测试以达到给定的置信水平(我怀疑这种信心水平与行业标准相比很高,但这可能只是傲慢) .如果我通常不会犯一个错误(比如在构造函数中设置错误的变量),我不会测试它.我确实倾向于理解测试错误,所以当我有复杂条件的逻辑时我会格外小心.在对团队进行编码时,我会修改策略以仔细测试我们共同出错的代码.
不同的人会根据这个哲学有不同的测试策略,但这对我来说似乎是合理的,因为对于测试如何最适合编码的内循环的理解不成熟.从现在起十年或二十年后,我们可能会有一个更普遍的理论,即哪些测试要写,哪些测试不写,以及如何区分.与此同时,实验似乎是有序的.
为您希望破坏的事物和边缘情况编写单元测试.之后,应该在bug报告进入时添加测试用例 - 在编写bug修复之前.然后开发人员可以确信:
错误是固定的;
该错误不会再出现.
根据所附的评论 - 我想这种编写单元测试的方法可能会导致问题,如果在给定的类中发现了大量的错误.这可能是谨慎有用的地方 - 仅针对可能重新发生的错误或重新发生会导致严重问题的错误添加单元测试.我发现单元测试中的集成测试测量在这些场景中会有所帮助 - 测试代码路径更高的代码可以覆盖更低的代码路径.
一切都应尽可能简单,但并不简单. - A.爱因斯坦
关于TDD最容易被误解的事情之一就是其中的第一个字.测试.这就是BDD出现的原因.因为人们并不真正理解第一个D是重要的,即Driven.我们都倾向于对测试有所了解,对设计的驱动有点关注.我想这是对你的问题的一个模糊的答案,但你应该考虑如何驱动你的代码,而不是你实际测试的; 这是Coverage工具可以帮助您的东西.设计是一个更大,更有问题的问题.
对于那些建议测试"一切"的人:意识到"完全测试"一种方法,例如int square(int x)需要大约40亿个常见语言和典型环境的测试用例.
事实上,它甚至更糟的是:一种方法void setX(int newX)也有责任不改变之外的任何其他成员的价值观x-你测试的是obj.y,obj.z等所有调用后保持不变obj.setX(42);？
测试"一切"的子集是唯一可行的. 一旦你接受了这一点,考虑不测试不可思议的基本行为就变得更加可口了.每个程序员都有bug位置的概率分布 ; 聪明的方法是将精力集中在测试区域,在这些区域中您可以估算出错误概率很高.
经典的答案是"测试任何可能破坏的东西".我认为这意味着测试setter和getter除了set或get之外什么也不做,可能是太多的测试,不需要花时间.除非你的IDE为你写那些,否则你也可以.
如果你的构造函数没有设置属性可能会导致以后出错,那么测试它们的设置并不过分.
我编写测试来涵盖我将要编写的类的假设.测试强制执行要求.基本上,如果x永远不会是3,例如,我将确保有一个涵盖该要求的测试.
总是如果我不写一个测试来覆盖一个条件,它将在"人类"测试期间出现.我当然会写一个,但我宁愿早点抓住它们.我认为关键在于测试是乏味的(可能)但是必要的.我写了足够的测试来完成,但不过是这样.
现在跳过简单测试的部分问题在于,将来重构可能会使这个简单的属性变得非常复杂,并且有很多逻辑.我认为最好的想法是您可以使用测试来验证模块的要求.如果当你通过X时你应该回Y,那就是你要测试的.然后,当您稍后更改代码时,您可以验证X是否为Y,并且您可以为A添加测试,以便在以后添加该需求时为您提供B.
我发现在初始开发编写测试期间花费的时间在第一次或第二次错误修复中得到了回报.能够获取你在3个月内没有看过的代码并且合理地确定你的修复程序涵盖了所有的情况,并且"可能"不会破坏任何东西是非常有价值的.您还会发现,单元测试将有助于远远超出堆栈跟踪等错误分类.了解应用程序的各个部分如何工作和失败,可以深入了解它们为什么工作或整体失败.
京公网安备 11010802040832号 | 京ICP备19059560号-6 