TDD (测试驱动开发) 常见问题

TDD · hkliya · Created at · Last by hkliya Replied at · 1663 hits
1

刚写了一个测试,还没写实现。明知道运行测试一定会报错,为什么还要去运行?

其实测试的运行结果并非只有通过与不通过两种,因为不通过时有很多种可能。所以在明知道一定失败的情况下去运行测试,目的是看看是不是报了期望的那个错误。

小步快走确实好,但真的需要这么小步吗?

步子迈太大,容易扯着蛋。
练习的时候需要养成小步的习惯,工作的时候可以自由切换步子的大小。
当你自信的时候步子就可以大点,当你不太自信的时候就可以立即切换到小步的模式。
如果只会大步,就难以再小步了。

测试代码是否会成为维护的负担?

维护时也遵循TDD流程,先修改测试代码成需求变更后的样子,让测试失败,再修改产品代码使其通过。
这样你就不是在维护测试用例,而是在利用测试用例。

为什么要快速实现?

其实是用二分查找法隔离问题,通过 hardcode 实现通过测试后,就基本确定测试是没有问题,这时再去实现产品代码,如果测试不通过,就是产品代码的问题。
所以小步快走主要是为了隔离问题,也就是你可以告别 Debug 了。

为什么测试代码要很简单?

如果一个测试失败了,修复的时候是改测试代码而不是产品代码,那就是测试代码写的不好。
当测试代码要足够简单,如果一个测试失败了,就有足够信心断定一定是产品代码的问题。


「软件匠艺社区」旨在传播匠艺精神,通过分享好的「工作方式」和「习惯」以帮助程序员更加快乐高效地编程。
共收到 6 条回复
30

『刚写了一个测试,还没写实现。明知道运行测试一定会报错,为什么还要去运行?』

其实还有一条,『如果追寻TDD,加了一个测试,测试没挂,说明这个测试用例不够好』。

个人总结的一些比较暴力的原则:

改变代码行为,测试必挂。
新增测试用例,测试必挂。
要改代码,先改测试。
要删代码,必挂测试。

30
lvjian700 · #2 ·

『测试代码是否会成为维护的负担?』

测试本身不会成负担,但是随着测试增长,测试也需要重构。

非TDD出来的职责不单一的代码,这类代码的测试用例非常写,存在大量重复的测试代码。这个维护成本,吐血。

我们项目要求 100% code coverage,这种补出来的测试覆盖率会是噩梦。

46

测试接口,不要测试实现。这样测试比较稳定,而且数量大为减少。

79

『为什么测试代码要很简单?』
简单就是为了一句话:不靠调试,靠测试

相比这个问题,“如何把测试代码写的简单?”是个不小的话题,大多数人TDD都会栽在上面

1
hkliya · #5 ·

#3楼 @chenge 同意。自上而上的测试,更关注行为,而不是实现。后被的测试容易写成白盒测试。

1
hkliya · #6 ·

#4楼 @hxfirefox 看到你的博客有一些持续集成,重构,自动化测试的文章,欢迎分享到这边来哦。

需要 Sign In 后回复方可回复, 如果你还没有账号你可以 Sign Up 一个帐号。