我一直试图加入TDD的潮流已经有一段时间了,除了一件至关重要的事情之外,它一直很顺利,通常我最终做的是开发后测试.
我需要心理转变,我想知道你是如何强迫自己先写测试的？
Bar*_*ark 26
我的心理转变是意识到TDD是关于设计,而不是测试.TDD允许您批判性地推断您正在构建的事物的API.首先编写测试,并且通常非常清楚API最方便和最合适.然后编写您的实现.
当然你也应该编写测试(回归测试,集成测试等).TDD通常会产生良好的设计,但不一定是良好的测试代码.
Ips*_*gle 21
当我读到某个引用(我记不清哪里)时,对于我来说,一个重要的时刻来自于测试的胜利时刻是测试从红色变为绿色的时刻.
这可能是你之前读过的所有内容,但除非我从一个失败的测试开始,并且它成为一个通过的测试,那就是我获得巨大的心理益处.从红色变为绿色感觉很好.如果你坚持将这一时刻交给自己,那就会让人上瘾,然后让自己做得更容易.
但对我而言,诀窍就是孤立那一刻并陶醉其中.
一旦我开始利用依赖注入,我的类变得更小,更专业,这使我能够编写简单的单元测试来确认它们的工作.鉴于我知道我的班级必须通过工作的测试数量有限,我的TDD工作的目标变得更加明确.由于依赖于外部资源,以及将模拟/存根/伪对象注入SUT以缩小测试焦点所需的单元测试,因此更容易识别哪些类需要集成测试.
我意识到这可能不适合每个人,而且许多开发者都不喜欢这个想法.但是我发现,如果我将程序与同时也致力于TDD的人配对,我们倾向于"保持彼此诚实",并且远远超过我自己单纯编程的意愿.
如果您有一个通用的测试框架,它会有所帮助
拥有适用于您运行的各种测试的通用函数库.然后重新使用它们作为构建块来为您正在进行的项目构建测试.
要实现这一目标,请注意您在之后编写的测试中所做的常见事情.将它们逐一抽象到广义库中.
这样做可以让您轻松快速地执行许多更简单的测试,而无需重新执行枯燥且耗时的测试驱动程序代码,而是专注于实际的测试用例.
做"测试作为文档"的方法.不要在未通过适当测试备份的文档中添加/更改任何措辞.
这样可以节省时间 - 您不必再重新解析文档/要求,只需稍后构建测试 - 以及帮助您提出的心理转变.
逐步逐步添加新功能/更改的测试,因为它们正在开始工作.
没有人喜欢改变冷火鸡的方式 - 人性.让好习惯溜进去,最终成为第二天性.
立即预算在项目开发计划开始时编写测试的时间
这将迫使您养成适当的习惯(假设您倾向于遵循您的项目计划)并保护您免于因为构建测试所花费的"额外"时间而超过截止日期.
当然,TDD的"额外"时间最终节省了净时间,但在项目的最初阶段并不总能实现,这给TDD实践带来了负面压力("原型截图在哪里???什么你是说你还在写测试吗？").
此外,尝试遵循小型一用途类和功能的常规推荐做法.这 - 在所有其他好处中 - 允许更容易的单元测试编写.结合#2(通过将单元测试作为API文档的一部分,在设计API时),以及您的API设计"神奇地"改进,因为您基于它们编写测试时立即开始注意弱点.正如其他人所指出的那样,使用某种依赖注入模式/框架有助于简化构建测试.