测试驱动开发的过程

       终于开始重视代码质量，但是关于代码如何写得更高的质量依旧非常的困惑和不解。最近希望尝试通过测试驱动开发的方式来提高自己的代码质量，尝试了几天了，中间虽然有的过程会走回老路子，总是会忘记先写测试再写代码，尤其是在改问题的时候，写新功能倒不会出现这样的问题，能够很好的控制，思维习惯还需要继续去养成。

       在测试驱动开发的过程中，最难的如何做到小步前进，有时候会发现写一个功能的时候迈出的步子过大，就会导致单元测试不全面，导致单元测试的覆盖率不够，尤其是逻辑覆盖率。

所以想到一个过程，是否能够预先想好要处理的情形，然后编写好测试用例，然后把测试用例转变成单元测试代码，测试用例要保证全面，由于测试用例是先于代码编写，而且只是文字表述和面对外在表现的功能，能够更好的克服人的惰性，能够测试到更多的流程，然后再转换成代码。

然后代码总是需要不停的重构的，第一次写出来的代码基本上都是按照业务逻辑编写，但是这个不一定是最好的组织方式，所以需要不断的重构，和重新组织，甚至要完整的重新设计。这个时候很难做到的是：保证单元测试先于代码重构，总是走回老路子，把代码写了才去补充单元测试，改完成就有点忐忑的感觉。还要进一步，养成以编写单元测试开始的习惯。

 

以后要坚持一下流程：

准备测试用例->编写测试代码->编写正式代码->单元测试通过->重构->编写测试用例以此循环

 

另外，在功能测试阶段，我们会发现有功能性bug。这种时候说明，单元测试的测试用例不够，需要补充单元测试用例，所以先补充单元测试用例，再改bug，这样才能保证下次同样的bug不会出现，让测试用例能够可以持续的回归。