手动测试驱动编程

Manual Test-Driven Programming

Talk About TDD

这个题目的断句应该是用手动的测试来驱动编程。我一直认为TDD就是要自动化测试驱动编程，写每一行代码前都要写好test case. 当然这在Java开发中很容易实现，因为有JUnit，也许自动化测试驱动编程的思想就是从JUnit来的吧。

然而开发工作不可能完全用Java写。网络应用在前端的一些功能不可避免地会用到JavaScript, 给网页调整形式的时候也会修改很多css文件，随着一个项目的日益推进，它用到的技术种类只会越来越多，这就给TDD带来了不小的challenge.

坚持自动化测试驱动是有可能的，JavaScript有Karma做单元测试，前端的测试也可以通过Firefox的一些插件实现，但是这一切的开销太大。学习用Karma做单元测试花费了我很多时间，我现在基本会用了这个库，但是每次开发测试也还是要花费很多时间，因为你需要想好页面的结构，然后给JavaScript一个合适的输出方式。本质上和JUnit类似，也许我在更熟练地用Karma以后会在写测试方面提高效率，但是一个项目是有ddl的，为了进度只好做一些妥协。

不自动化测试就不是TDD了吗？当然不是，如果自动化是标准，那流行的说法应该是ATDD(Automatic Test Driven Programming), 所以只要你有测试，无论是单元测试的形式还是手动的，在脑中的形式，都可以声称自己是测试驱动。相比下，手动测试驱动每一次测试的时间会比较长，而且手动容易出错，但我用checklist记下每一个步骤，就最大限度地减少了出错率。

这些思考来源于最近开发的网络应用。页面的元素根据PM的需求会时常改动，如果要开发自动化的脚本，用Firefox的插件来模拟用户的页面操作，这好处当然是明显的，但开发这些脚本的时间是巨大的，敏捷开发需要较短的开发周期，在手动测试开销不大的情况下，我还是愿意每一次改动以后都自己走一遍checklist上的测试流程