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