为何使用测试驱动开发

之前的一篇文章提到了项目中的bug问题，诚然，bug是无法避免的，但是优秀的开发模式以及测试方法会极大的减少bug数量，使得软件能够正常的运行并且不断的迭代。

那又是什么引起我改进我的开发模式？那还是我在实践《Ray Tracing in One Week》那本书的时候，当时记得有一个函数 hit 接受一个 tMin以及tMax作为ray的参数t的取值范围，我当时取得是tMin = 0，书中取的是 0.001 结果错误就出现了。我渲染出的图片出现了密密麻麻的黑点，经过3小时的仔细排查，发现是tMin出现了问题。就因为一个小小的浮点数，就会引起项目渲染效果的巨大变化。

这一事件深深触动了我，想了许久，还是因为我对我写的代码不理解并且对项目的运行状态不自信，于是我开始重视图形学理论的学习以及测试的必要性，不再单纯的直接按照作者的原意重新把代码码下来。于是，我接触到了TDD，一种先写测试后编码的开发方式，尽管一开始看起来有点怪，但是在不断的进行测试 -> 编码通过 -> 重构的循环后，我发现我对项目的运行状态有了把握，即使某一次编码之后，致使项目出现了bug，我也可以很轻松的定位到底是哪段代码出了问题；即使无法解决，也可以通过版本控制系统，回到上一次的状态。于是，在这不断的迭代中，我完成了我这个项目，目前这个项目，已经有了大约1万行的代码（不包含测试代码），但是运行状态依旧可控。我可以轻松的添加一些特性，并且将这些特性安全的引入到系统中。

至于为什么tMin要是0.001？主要是浮点数精度的问题。由于浮点数精度的限制，无法表示精确的实数，于是在一些算术操作之中，引入了误差，产生了自相交（self intersection）的情况。为了解决这种非常小的t产生的问题，往往需要去除掉这种无用的自相交（当然这种方法也不好，会裁切掉大量的光线，并且依旧会产生自相交的问题）。