第三天：
第三天是重头戏，早早的开始编写测试用例，因为第三天的测试用例是最重要的。
测试用例：都不为空的话，$old里面的元素被$new分别覆盖
测试代码：
|
<?php $ret = lz_array_merge($new, $old); |
预期结果是：
| <?php $result = array( 'apple' => 100, 'banana' => 100, ); ?> |
那么我们开始编写代码：
| <?php function lz_array_merge($new, $old) { if(count($new) == 0 || count($old) == 0) return array(); foreach($new as $key => $value) { $old[$key] = $value; } return $old; } ?> |
运行测试，发现三个测试用例都通过了，这让我们兴奋不已，第三天搞定了！但是依旧，我们要有一个重构的习惯，看一下有没有哪些可以去掉的代码。我们发现，判断数组是否为空是不需要的，那么我们就重构代码如下：
| <?php function lz_array_merge($new, $old) { foreach($new as $key => $value) { $old[$key] = $value; } return $old; } ?> |
至此，我们三天的工作就完成了。一个完整的TDD流程也就走过一次了。
这里也许你会问根据我们第三天的重构，我们前两天完全是没有必要的啊！没有产出一行代码。我不这么看，我认为前两天最大的贡献是我们产出了可被回归的自动化测试用例，以及测试驱动本身的流程，我们的代码得到了最好的保护。
经过这个流程，也许你会对测试驱动的过程有一个比较好的认识。总结一下测试驱动的优点：
● 可回归的自动化代码产出
● 在开发前思考开发的调用
● 开发人员有了边界，每天的工作就是测试用例的完成
● 为其他开发人员提供了开发代码调用的示例
