【连载】嵌入式测试驱动开发(6)

    /***直接写产品代码最快？***/

    我们可能经常有这样一种错觉，好像我们首先开发产品代码会比我们先写测试驱动要快很多，其实这样单纯的看待正式产品代码的书写进度来判定产品软件的开发进度是非常片面的。我们应该还需要考虑我们后期的调试和维护时间，和维护代价等！

     直接写产品代码，其实是一种后期测试的方法，而我们的TDD是测试驱动在前产品代码在后的一种方法，它能够实际影响到我们的产品代码的健壮性和可维护性等方面的性能效果，减少更多的代码上缺陷问题！更重要的是TDD后续的回归测试中的回报率是递增的，而比如后期测试、手动测试、单步测试等回报率都是递减的！

    /***TDD注意事项***/

    1)我们的测试代码也是需要维护的，这样才能在后续的回归测试中获得更大的回报率。

     2)我们采用TDD也不可能避免所有的bug，因为我们的测试用例不可能想得那么全。

     3)可能我们已经写好了部分的代码或者是库，这个时候却没有写测试代码，我们可以一边写产品代码一边加入TDD进行测试，也不要停下写产品代码而去写TDD，而是需要修改产品代码的时候进行加入。

     /***如何测试依赖性模块***/

     我们都知道像前面几小节提到的模块都是一些完全独立的，其输出仅仅只与输入的参数有关系！这样的测试模块对于TDD来说就再好不过了，可是在我们的嵌入式软件开发中系统的运行，每个模块并不是完全独立的，可能需要等待某个模块的运行结果或者是根据其他模块的运行状态来进行自身状态的更新！那么我们该如何使用TDD测试这部分中间的代码呢？下面就让我们详细聊一聊：

    1）伪装法：我们前面在led的测试用例也简单的提到过这个伪装法的使用，就是通过为被测试的代码提供数据、函数或者是库。其被测试的代码并不知道其真实的存在！

          同时我们也要理解的是我们的伪装代码并不是一定要完成所代替模块的所有的功能，我们仅需要为被测试模块提供测试所需要的返回值，或者是用于捕获相关的数据，也可以用于获取被测试模块所发出的相关参数。

    2）软件的运行都是多个模块相互配合来完成多项复杂的任务，所以有些中间层的模块并不是完全独立的。也不是说所有的被测试代码都需要通过伪装代码来进行测试。我们选择该方法的原因如下：

          1、当我们没有硬件平台的时候，或者是硬件平台不足够的使用，使用该方法能够帮助我们进行硬件和软件的并行开发。

          2、真实的平台其输入被测试模块的控制数据需要很长的时间，这样非常影响到我们观察整个测试过程，这个时候我们可以伪装输入，过得更快的测试。

          3、我们被测试的模块通过控制其他模块并获得其他依赖的模块所返回的数据来进行下一次状态的更新。不过有时候我们依赖的这个模块可能运行时间较长才返回给被测试模块的数据，这样就非常影响我们的测试和开发进度！所以我们可以替代掉该所依赖的测试模块，加快测试。

       好了，这里是公众号“最后一个bug”，感谢各位的关注，也希望各位分享转发，下一期我将为这种测试伪装法的几种实现方法做详述，从我的工作经验来看，目前软件开发是经常使用的！我们下期见！