测试如何驱动开发

需求：反转一个句子
我可能会写出以下的测试——写一个测试，然后写代码让测试通过，然后再写下一个测试。
自己看吧。

public class StringReverseTest {  
  # Test 1
  public void testShouldSplitSentenceIntoWords(){  
    StringReverser sr=new StringReverser();  
    String str = "This is a sentence";  
    Assert.assertEquals(4, sr.split(str).size());
    Assert.assertEquals("sentence", sr.split(str).get(0));  
    Assert.assertEquals("a", sr.split(str).get(1));  
    Assert.assertEquals("is", sr.split(str).get(2));  
    Assert.assertEquals("This", sr.split(str).get(3));  
  }  
  # Test 2
  public void testShouldReverseSentence(){  
    StringReverser sr=new StringReverser();  
    String str = "Tdd is a software devolopment technology";  
    Assert.assertEquals("technology devolopment software a is Tdd",sr.reverse(str));  
  }  
  # Test 3
  public void testShouldAlwaysReverseSentences(){  
    StringReverser sr=new StringReverser();  
    String str = "This is Yet Another sentence";  
    Assert.assertEquals("sentence Another Yet is This",sr.reverse(str));  
  }  
}  

reverse(null),
reverse(""),
reverse(" "),
reverse("\t"),
reverse("\r\n"),
reverse("a"),
reverse("a "),
reverse(" a"),
reverse("a b"),
reverse("Tdd is a software development technology")

有意思，gigix和taowen的帖子正好显示了测试完整度的问题。一个测试要写到甚么程度才足够？

TDD的好处就不用说了，我感到最难把握的就是测试完整度。像gigix的测试就是只覆盖到自己要实现的功能就好——只测常见情况。而taowen的测试则是把所有可能出现的情况都测试到了。

测试当然是越详细越好，但是代价就是代码量也迅速增多，而且更重要的是写测试的时间长了，必须精心构造测试数据和条件，我觉得会把我的注意力从实现程序功能上转到如何让测试更完备上来。

所以我是觉得在开发阶段还是不要太花时间在测试的完整度上，只保证基本功能的测到了就好。

用gigix的直到有问题，再加测试。
PS：程序员写的东西不能代替测试员的存在。

测试是测试，测试驱动是测试驱动，别把两个东西搞混了。说白了测试驱动还是需求驱动，而测试则需要考虑更多的东西。gigix的做法在tdd看来很棒，但是在测试角度看则很不完整。

还是o6z这话说的透啊，我还真费了不少时间才意识到这点，开始的时候总是想把单元测试写完整些，生怕遗漏了些甚么

    上边一共三句话，前两句是赞同的。 其实测试驱动还是需求驱动，story-->test-->code， 而我们说的普通的test是这样形成的，story-->design-->code--->test。

     第三句不赞成，gigix的做法不是tdd，taowen的才是tdd，第三句的做法是“友情驱动” 

非也，第三句才是我说的重点。
实际上这里确实存在一些模糊的问题。比如如果这个字符串为空如何，为单一词汇又如何，又如果是为一个超过1k长度的字符串如何，超过1m又如何，。。。。。。。
实际上这里的问题你说完全是基于功能的还是基于程序结构的呢？
不过一般情况下客户会给你个比较清楚的解释，不过也有模糊的地方。比如客户说我干嘛要输入一个空字符呢，于是你可以认为这个其实是一种客户误操作的结果，大概应该算在测试范畴。而如果是单一词汇，客户可能会说，这个我有时候也可能会做，或者是我随手按了回车，这个时候这大概算是功能范畴的了。而显然客户对边界的问题并不敏感，这个时候则基本属于测试范畴。
TDD的做法并不是要你在最早就准备好一个完整的测试系统，而是要你通过写准对需求的测试，也就是针对功能的测试，来因对性的完成你的代码。这是一个由需求，转换为针对测试，在因对的代码的过程。

      那ozzzzzz怎么看gigix 关于testShouldSplitSentenceIntoWords这个测试？

这个测试就是所谓的“设计过程”
实际上照我真实的想法，我是不想写这个测试的，因为这个需求实在太简单了
不过为了说明这里确实有“设计”的存在……
我把一个大的问题分解成两个小的问题，先用测试驱动解决第一个，再用测试驱动解决第二个
就是这样