Closed xiaohulu closed 10 years ago
转载自孜孜不倦——纲举目张，测试用例就是纲
纲,是鱼网上的总绳，目是鱼网上的一个个网格。本意是“把大绳子一提起来，一个个网眼就都张开”，详细解释请参考百度词典。
潜在代码的海洋里，苦于理不出头绪？
在程序开发中，面对众多的别人写的，很久以前写的，以及将要加入进来的代码，我们又如何能做到纲举目张，条例清晰呢？
任何一次编码，不论是新增功能，修改bug，还是重构优化，都是由一系列有一定关联的子活动组成的，都需要修改散落在很多处的代码段，因此从哪个活动开始，或者从哪个文件入手，就需要快速的抉择。正确的选择，可以让整个编码的思路顺畅连贯，不会出现丢三落四，改了这一处，忘了那一处，改好这个功能点，却引入了其他bug。不至于求助IDE的debug跟踪，让IDE告诉你哪里出错了。开发人员要始终处于主动。
盲目被动，则工作效率下降，并且工作质量得不到保障，最重要的是在这个活动中，只是对个别的代码片段有一个重新认识的过程，但是对整个代码的轮廓，对功能点的理解，却没有建立起来。因此在我们的编码工作中，经常出现编码完成了，但是这段编码要完成的功能，或者实现的用户需求，心里却没有底，甚至到项目验收完成，开发人员对需求的理解仍停留在一知半解上。
这么多问题，那么我们怎么解决呢？ 上面说的一系列编码子活动或者散落在多处的代码片段就是“目”，要统一管理好“目”，快速的理清楚思路，做到有条不紊，就需要找到“纲”。而在程序开发中如何做到纲举目张，条理清晰呢？答案是合理使用测试驱动开发，除了知道怎么编写测试用例(要真正的应用在平常工作中)，还要知道为什么要用，用了之后，除了要多维护一套测试用例代码之外，对开发人员还有什么好处呢？好处就是 测试用例就是那个纲，可以贯穿于整个编码活动，集中注意力，逐个的完成各个编码子活动 。
测试用例是整个编码活动的入口，也就是起点，不论是新增需求，还是修改bug，都是先从测试用例开始，先梳理一遍测试用例，用测试用例详细描述用户需求，或者编写测试用例让bug重现，然后在测试用例驱动之下逐步的实现或重构实现代码。这样从测试用例发起的滚雪球式的迭代开发，可以让测试用例覆盖到代码的大多数地方。重要的是这种开发方式，促使我们不断的完善测试用例。
这就是一个良性循环，先让测试用例暴露出问题，最后让测试用例全部通过，在一切变绿的那一个时刻，就是整个编码活动结束的时候。
也就是说在我们作为起点运行测试用例时，它是都可以通过的，然后我们“制造困难”，让它无法通过，接着做一次"修复手术"，让测试用例又恢复到都可以通过的状态。这个过程正应了认识论中的“认识是一个否定再否定”的过程。不管是认识，还是编码，包括生活中的一切活动，我们需要对某个对象做“加法”时，都需要经历这样一个过程。
说的再明白，分析的再透彻，不应用到实践中去，一切白搭。当你准备往文件中编写代码，直接添加功能的时候，请你马上停下来，静静的想一想上面的道理，希望最后你开心的将鼠标移到了测试用例文件图标上，清脆的“咔咔”一声，点开测试用例文件，开始你新一轮的工作。逐步的养成这个好习惯，并固化为编码工作中不可或缺的一部分。快乐编码，从这一刻开始。
测试驱动开发的好处还有很多很多，这里不一一罗列。不要沉浸在了解好处的乐趣之中；而要满手泥，一身汗的体会着其中的乐趣。
纲举目张，测试用例就是纲
转载自孜孜不倦——纲举目张，测试用例就是纲
纲举目张
纲,是鱼网上的总绳，目是鱼网上的一个个网格。本意是“把大绳子一提起来，一个个网眼就都张开”，详细解释请参考百度词典。
潜在代码的海洋里
潜在代码的海洋里，苦于理不出头绪？
在程序开发中，面对众多的别人写的，很久以前写的，以及将要加入进来的代码，我们又如何能做到纲举目张，条例清晰呢？
任何一次编码，不论是新增功能，修改bug，还是重构优化，都是由一系列有一定关联的子活动组成的，都需要修改散落在很多处的代码段，因此从哪个活动开始，或者从哪个文件入手，就需要快速的抉择。正确的选择，可以让整个编码的思路顺畅连贯，不会出现丢三落四，改了这一处，忘了那一处，改好这个功能点，却引入了其他bug。不至于求助IDE的debug跟踪，让IDE告诉你哪里出错了。开发人员要始终处于主动。
盲目被动，则工作效率下降，并且工作质量得不到保障，最重要的是在这个活动中，只是对个别的代码片段有一个重新认识的过程，但是对整个代码的轮廓，对功能点的理解，却没有建立起来。因此在我们的编码工作中，经常出现编码完成了，但是这段编码要完成的功能，或者实现的用户需求，心里却没有底，甚至到项目验收完成，开发人员对需求的理解仍停留在一知半解上。
测试用例就是纲
这么多问题，那么我们怎么解决呢？ 上面说的一系列编码子活动或者散落在多处的代码片段就是“目”，要统一管理好“目”，快速的理清楚思路，做到有条不紊，就需要找到“纲”。而在程序开发中如何做到纲举目张，条理清晰呢？答案是合理使用测试驱动开发，除了知道怎么编写测试用例(要真正的应用在平常工作中)，还要知道为什么要用，用了之后，除了要多维护一套测试用例代码之外，对开发人员还有什么好处呢？好处就是 测试用例就是那个纲，可以贯穿于整个编码活动，集中注意力，逐个的完成各个编码子活动 。
测试用例是起点
测试用例是整个编码活动的入口，也就是起点，不论是新增需求，还是修改bug，都是先从测试用例开始，先梳理一遍测试用例，用测试用例详细描述用户需求，或者编写测试用例让bug重现，然后在测试用例驱动之下逐步的实现或重构实现代码。这样从测试用例发起的滚雪球式的迭代开发，可以让测试用例覆盖到代码的大多数地方。重要的是这种开发方式，促使我们不断的完善测试用例。
测试用例也是终点
这就是一个良性循环，先让测试用例暴露出问题，最后让测试用例全部通过，在一切变绿的那一个时刻，就是整个编码活动结束的时候。
也就是说在我们作为起点运行测试用例时，它是都可以通过的，然后我们“制造困难”，让它无法通过，接着做一次"修复手术"，让测试用例又恢复到都可以通过的状态。这个过程正应了认识论中的“认识是一个否定再否定”的过程。不管是认识，还是编码，包括生活中的一切活动，我们需要对某个对象做“加法”时，都需要经历这样一个过程。
养成习惯
说的再明白，分析的再透彻，不应用到实践中去，一切白搭。当你准备往文件中编写代码，直接添加功能的时候，请你马上停下来，静静的想一想上面的道理，希望最后你开心的将鼠标移到了测试用例文件图标上，清脆的“咔咔”一声，点开测试用例文件，开始你新一轮的工作。逐步的养成这个好习惯，并固化为编码工作中不可或缺的一部分。快乐编码，从这一刻开始。
结语
测试驱动开发的好处还有很多很多，这里不一一罗列。不要沉浸在了解好处的乐趣之中；而要满手泥，一身汗的体会着其中的乐趣。