他山之石：单元测试使编程更有趣

Submitted by mpeg on 2008, July 30, 1:47 PM. English

原文链接：http://techblog.tilllate.com/2008/06/01/unit-testing-makes-coding-more-fun/
Unit testing makes coding more fun
单元测试使编程更有趣

“unit testing is a test that validates that individual units of source code are working properly”, that’s what Wikipedia says about unit testing. That’s general knowledge.
“单元测试是对源代码每一个程序单元进行的测试，它检查程序模块是否正确地实现了规定的功能。”，这是维基百科(http://en.wikipedia.org/wiki/Unit_testing)上对单元测试的定义。大家也都普通这样认为的。

But what motivates me even more than the increased software quality is that it saves me development time. This sounds odd as you might believe that TDD means writing more code.
但对我而言，更刺激的是它不仅仅对提高代码质量有好处，而是节省了我的开发时间。如果你认为单元测试只是意味着编写更多的代码的话，那这样说也许会令你感到奇怪。

Here’s a real-life example:
下面是一个真实的例子：

For our internal invoicing system I had the task of changing the way we generate invoice numbers. Instead of a global number range each tilllate Ltd. subsidiary should receive it’s own distinct number range. And all invoices must have subsequent numbers to be compliant with the legal regulations. Invoices are being generated by about 100 staffs via a web front end. So I wrote the classes InvoiceNumber and InvoiceNumberFactory.
一次我担任了修改公司内部使用的发票系统生成发票号码方法的任务。老的方法使用统一的数字，而新的方法要求每个子公司都有自己不同的发票号码范围。所有的发票号码都必须是连续的数字并且符合有效性规则。发票是由大概100个左右的员工通过web前端生成的。因此我写了InvoiceNumber和InvoiceNumberFactory两个类。

Testing it manually: Boring!
手工测试？太无聊！

Now, how do I test them? Without a unit test framework I would have had to test it via the web based front end:
现在怎么去测试它们呢？如果没有一个单元测试框架我就只好通过web用手工来测试了：

Create a test customer (= fill out a form with about 30 fields, click save, wait)
创建一个测试帐号（= 填写大概30个字段的表单，然后按保存，等待…)

Create a new order (= fill out two forms with each 10 fields, click save, wait)
生成了新的订单 (= 填写两个表单，每个表章大概10个字段，然后按保存，等待…)

Create an invoice (= another form)
生成发票 (= 又是另一个表单)

Check if the generated invoice number is correct
检查生成的发票号码是否正确

If not, delete all created db entries and start over again
如果不正确，删除数据库中所有的相应记录接着再从头开始…

My code would not have worked immediately. I would have had to go through the procedure above over and over again. Each iteration was 120 seconds of clicking and waiting. YAWN.
我的程序不会一次就通过。这样我将不得不一次又一次的重复上面的操作。每次操作都大约需要120秒的时间来按确定然后等待。想想看这有多乏味！

Speeding it up by automating the test
使用自动测试来加速测试过程

By using unit tests I was able to avoid this manual labor: I set up my test environment (1 - 3) programatically in my setUp method. I cleaned up everything (step 5) in the tearDown method of my test. To run the test I just called it via the shell:
通过单元测试的方法使我避免了这样的手工劳动：在setUp方法中我用程序自动生成了测试环境（第1-3步），在tearDown方法中清除了所有的数据（第5步）。这样只需要在shell中调用如下的命令就可以进行测试:

pluto unit # php -f test_InvoiceNumber.php TestInvoiceNumber
OK
Test cases run: 1/1, Passes: 20, Failures: 0, Exceptions: 0

The whole set up, testing and tear down process was done programmatically. Time elapsed: 0.54 seconds.
整个设置，测试和结束过程全部使用程序自动完成。共耗时0.54秒。

Thats 240 times faster than the manual testing via the web front end.*
这比用web浏览器手工测试快了240倍!

And definitely much more fun!
而且肯定有趣得多！

*sure, writing the test is not free. But in the bottom line I believe it save me time.
注:当然编写测试代码也需要时间。但至少它节省了我的时间。