Coding道场：第一次

10/23日，我在部门内部进行了一次内部学习，使用目前流行的Coding Dojo（道场）方式，进行了TDD开发的演练。 演练的题目以下：

 

 

有关Coding道场的介绍，请自行百度一下，我就再也不多作介绍了。

 

从效果来看，基本达到了传达TDD是什么样的开发方式的目的。尤为是你们从最初满脑子如何实现这个程序，怎样去设计算法，逐渐转变为了先想如何测试，从最简单的实现开始，最终演化成最终的设计。固然，目前为止，参加人员也只是理解了TDD是一个什么样的开发方式而已，还谈不到真正使用TDD进行开发。这须要一个更加长期的自我训练和使用的过程。 使用TDD，最主要的是一种思惟方式的变化。

首先：要坚信全部的程序皆可测，若是不能测试，不是产品的特性致使，而是本身的能力不足致使，设计上有问题。所以必须从设计上加以改变，使得程序可测。如通常认为曲线的显示是否正常，是没法使用自动测试的。换个角度：若是显示只是一个数据-坐标的转换的话，测试的重点就变成了数据是否正确，而这一点是彻底可测的。

其次：虽然须要全局的考虑，可是要从简单入手，演进式设计。

这一点，在本次道场演练中体现的就很明显，这次道场开始，不少人的想法就是，创建某种算法，将须要的字符显示出来。因而第一个函数就是：void DisplaySegmentDigital(String input)，而后再写那些子函数。如何测试这个函数？这是一个输出到屏幕显示的函数，它只能用眼来判断，显然不适合自动测试或者单元测试。因此，TDD不是一个先实现框架，再实现具体功能的作法。输出到屏幕，只是最后的一个过程，也是一个简单的过程，所以能够没必要做为重点。重点在于显示的数据是什么？因此，函数就变为了：String DisplaySegmentDigital(String input)。这个时候，这个函数再也不是向屏幕输出，而是输出一个字符串，再由另一个字符串显示函数完成向屏幕的输出。而原来这个函数就变得可测了。因而，第一个测试函数被写出来了：

String strText = "910"; String strTextResult = "._.|_|..|.....|..|._.|.||_|";  

String strOutput = digitalSegment.DisplaySegmentDigital(strText);   

assertEquals(strOutput , strTextResult);

第一个测试顺利经过，由于实现很是简单：

public String DisplaySegmentDigital(String strText) {

    return "._.|_|..|.....|..|._.|.||_|";

}

接下来的困难是：下一个测试什么？测试“3456”的输出？OK，咱们先试试看，因而咱们想写第二个测试：

String strText = "3456"; String strTextResult = "？？？？？？？？";

问题接着出来了：这串问号该填什么？这样测试真的有意义么？几乎全部的人都直以为发现这里有问题。简短的讨论后，结论是应该测试每一个数字的显示，而非一个字符串。因而，测试变为：

String strText = "9"; String strTextResult = "._.|_|..|";  

String strOutput = digitalSegment.DisplaySegmentDigital(strText);  

assertEquals(strOutput , strTextResult);

实现变为：

public String DisplaySegmentDigital(String strText) {

 if(strText == "9")

  return "._.|_|..|";

 else

  return null;

}

实现后，接着测试：

strText = "1"; strTextResult = ".....|..|";  

strOutput = digitalSegment.DisplaySegmentDigital(strText);  

assertEquals(strOutput , strTextResult);

实现也变为：

public String DisplaySegmentDigital(String strText) {

 String[] strResult=new String[10];

 strResult[0]="._.|.||_|";

 strResult[1]=".....|..|";

 strResult[9]="._.|_|..|";

 return strResult[Integer.parseInt(strText)];

}

至此，很显然咱们的算法也就天然而然的诞生了。可能与不少人本身开始的算法设计不太同样，但也不该该差到哪里:)。这就是TDD演进式设计。

但有个问题，._.|_|..|是什么东东？我怎么知道最终输出是正确的。所以，咱们稍微改变了一下写法：

String strText = "9";   String strTextResult = "._." +
                                                                 "|_|" +
                                                                  "..|";     

String strOutput = digitalSegment.DisplaySegmentDigital(strText);

assertEquals(strOutput , strTextResult);

strText = "1";   

strTextResult = "..." +

                        "..|" +

                        "..|";     

strOutput = digitalSegment.DisplaySegmentDigital(strText);      

assertEquals(strOutput , strTextResult);

实现变为：

public String DisplaySegmentDigital(String strText) {

 String[] strResult=new String[10];

 strResult[0]="._." +

                     "|.|" +

                     "|_|";

 strResult[1]="..." +

                     "..|" +

                     "..|";

 strResult[9]="._." +

                    "|_|" +

                     "..|"; 

 return strResult[Integer.parseInt(strText)];

}

如今直观多了。

为何必定要变得直观，其目的不单纯是为了程序的易读性，更重要的是：测试不该该抄实现的代码，实现也不要抄测试的代码，不然后果很严重。写测试代码时，必须是含着测试的心态，含着使用者的心态去写测试代码，而非一门心思去想实现。若是这样，TDD就失败了。这也是为何TDD要求先写测试代码，再写实现代码的缘由。由于咱们一旦先想到了实现，那么接下来的测试，必然会跟着实现的逻辑走，从而违背“测试独立性”的原则。实现发生错误，测试也没法发现。

接下来须要整理一下代码，显然DisplaySegmentDigital这个函数名不是那么准确，后来议论了一番，得出的名字是：GetDigitalDisplayContent。结束后，我想GetDigitalFont可能更好。

好了，有关第一次道场就写到这里，留一个小小的问题：到目前为止咱们尚未设计显示的算法。为了便于输出，目前的设计如何改进？