如何开始TDD

TDD已经被证实为一项可以提高软件质量的基本实践，然而对于很多程序员来说，在抱着尝试一下的想法实践的时候，却困难重重。这里面有多方面的因素，比如环境，比如编程习惯，比如不会写测试用例等等。TDD是一项实践性很强的事，就像OO一样需要大量的实践来获得经验，因此如果能在平时养成写测试的习惯，从简单到复杂一点一点进行练习，就能慢慢的掌握TDD了。这里建议初学的人可以考虑先写代码后写测试，等到测试写的很熟练了再转到先写测试后写代码的阶段。

先说说如何先写代码再写测试：

我看到很多人在学习新技术或者写一些demo代码的时候，会使用winform或者console来获取输入与输出，如果是与UI无关的demo，我们同样可以使用测试框架来获得同样的甚至是更好的效果。

例如iSun写的快速排序，他使用了console来获取输入与输出，在调试阶段可能要一遍一遍的输入同样的测试数据（例如[3,4,2,6,1]），然后目视检查结果是否正确（[1,2,3,4,6]）。这样的问题在于，如果代码比较复杂，测试了很多次才做正确，这其中重复的输入与检查输出就成为了一项很烦人的体力劳动，不仅很花费时间而且容易使人烦躁和疲劳。当其他人拿到这段代码再自己的机器上运行时，也需要重新输入数据，检查输出。假如我拿到了这段代码，并进行了一些优化或重构，我还是要重复的输入同样的东西，检查输出，以确保程序的正确性。在这里我们就可以使用NUnit/xUnit.net等测试框架来自动化这个测试过程。

[Fact]
public void should_sort_array()
{
   var arr = new int[]{3,4,6,2,1};
   var expected = new int[]{1,2,3,4,6};

   var actual = QuickSort(arr);
   Assert.Equal(expected.Length, actual.Length);
   for(int i=0;i<actual.Length;i++)
   {
     Assert.Equal(expected[i],actual[i]); 
   }
}

 注：这里的代码只是演示用，没有运行过，不保证运行正确；另xUnit.net似乎有直接比较数组的Assert方法。

有些人说我很想做单元测试或TDD，但是我不会写测试用例。其实我们任何时候写程序，都要自己测试一下的，比如这个QuickSort，你的测试可能就是输入一个数组，然后看看输出是不是排好序了。那么这个就是一个测试用例，一系列的输入，获得一系列的输出，对于同样的输入，会有同样的输出。这里的输入可能是一些数据，也可能是一些动作（比如点击web页面上的某些按钮），输出可能是一组数据，也可能是一些动作或行为（比如点击web页面的按钮后，跳转到某个特定的页面）。因此只要你会写代码，就一定会测试；只要测试了，就一定会有测试用例，只是你自己没有察觉到而已。有些人也许会问，如果我写了测试了，那么QA/测试人员干什么呢？其实开发人员所写的测试用例只覆盖了很小的一部分，当然这些测试用例也是最常发生的，或者是最正常的情况，因此无需担心你的工作与QA重和的问题。

让我们看看对于这个QuickSort，我们还能写出哪些测试用例呢：

[Fact]
public void should_sort_empty_array()
{
   var arr = new int[]{};
   var expected = new int[]{};

   var actual = QuickSort(arr);
   AssertArrayEqual(expected, actual);
}

[Fact]
public void should_sort_array_with_only_one_element()
{
   var arr = new int[]{1};
   var expected = new int[]{1};

   var actual = QuickSort(arr);
   AssertArrayEqual(expected, actual);
}

[Fact]
public void should_sort_array_already_sorted()
{
   var arr = new int[]{1,2,3,4,5};
   var expected = new int[]{1,2,3,4,5};

   var actual = QuickSort(arr);
   AssertArrayEqual(expected, actual);
}

private void AssertArrayEqual(int[] expected, int[] actual)
{
   Assert.Equal(expected.Length, actual.Length);
   for(int i=0;i<actual.Length;i++)
   {
     Assert.Equal(expected[i],actual[i]); 
   }
}

 

好了，到这里你就可以安心的修改代码，无需一遍一遍的输入测试数据，检查输出，也不需要担心你的修改会使程序出错。 对于看代码的人来说，可以看到什么样的输入会获得什么样的输出，以及如何使用这个方法。当把代码下载下来研究的时候，也不需要自己输入测试数据了，如果想要换一个不同的测试数据，只要添加一个测试就行了。

那么如何先写测试后写代码呢?

前面说了，对于一段程序的测试其实就是一些输入与输出组成的测试用例，这些测试用例与你如何实现QuickSort方法毫无关系，因为QuickSort的功能就是排序，不管里面的代码如何实现，他都必须要完成排序的这个功能，因此只要根据排序的要求写就行了。一旦你熟悉了如何编写测试用例，如何考虑程序可能获得的各种输入，从后写测试到先写测试，只是一个改变习惯适应的过程，并不会很难。

倡议以后发表代码的同学，附上自动化测试（并注意代码风格、编码规范），于人于己都有好处。当然，决定权在你自己手里。