测试如何驱动开发

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

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));  
  }  
}  

评论

17 楼 Godlikeme 2007-09-20  

ozzzzzz 写道

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

这样理解也说得过去，kent beck可不是这么说得。
test-driven development书中例子里还是强调了测试的complete。

gigix的需求应该细化，对空句子，最长多长的句子，要达到的性能指标。

16 楼 hlxiong 2007-09-20  

我不太明白的是，Test2和Test3有什么不同？是不是它们的实现代码不同？

15 楼 ozzzzzz 2007-09-19  

balaschen 写道

ozzzzzz 写道

其实这里又有一个问题。
那就是如果是采取TDD的方式来说明问题，那么如果把test case作为一种说明需求的工具，那么我们就需要将真正的用于测试的test case和其分开标注。

是不是说，用来驱动实现的test case，包含了设计过程，关注实现细节，但用来描述需求的test case，是不包括设计过程的，不关注实现细节，这两种test case，要明确区分？

其实可以这样说，你看一段代码肯定首先想知道他是做啥的。这个时候你会发现，阅读有些test case只能让你云里雾里，而阅读有些则让你马上就知道这段代码的用途。其实找并不是这些test case写的有水平差别，而往往是有针对问题角度的差别。而进一步，你会发现阅读这些test case如果按照一定顺序，就会从最初的动机到最终的实现细节都有一个清晰的理解，而如果我们能够在写这些test case的时候就标注出这个理解顺序，将是十分核算的。而实际上很多时候我们书写的顺序就是最终我们适于阅读理解的顺序。

14 楼 balaschen 2007-09-19  

ozzzzzz 写道

其实这里又有一个问题。
那就是如果是采取TDD的方式来说明问题，那么如果把test case作为一种说明需求的工具，那么我们就需要将真正的用于测试的test case和其分开标注。

是不是说，用来驱动实现的test case，包含了设计过程，关注实现细节，但用来描述需求的test case，是不包括设计过程的，不关注实现细节，这两种test case，要明确区分？

13 楼 ozzzzzz 2007-09-19  

其实这里又有一个问题。
那就是如果是采取TDD的方式来说明问题，那么如果把test case作为一种说明需求的工具，那么我们就需要将真正的用于测试的test case和其分开标注。

12 楼 gigix 2007-09-19  

balaschen 写道

hostler 写道

ozzzzzz 写道

TDD的做法并不是要你在最早就准备好一个完整的测试系统，而是要你通过写准对需求的测试，也就是针对功能的测试，来因对性的完成你的代码。这是一个由需求，转换为针对测试，在因对的代码的过程。

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

如果从需求驱动的角度，没必要写testShouldSplitSentenceIntoWords这个测试，因为不同的实现方法，也许就不需要先把句子切分成单词。

所以我们说“TDD”。测试驱动开发，开发中的每“一步”都有测试来驱动。至于测试写到什么粒度，取决于你认为怎样的“一步”对于你来说是合适的。

11 楼 balaschen 2007-09-19  

hostler 写道

ozzzzzz 写道

TDD的做法并不是要你在最早就准备好一个完整的测试系统，而是要你通过写准对需求的测试，也就是针对功能的测试，来因对性的完成你的代码。这是一个由需求，转换为针对测试，在因对的代码的过程。

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

如果从需求驱动的角度，没必要写testShouldSplitSentenceIntoWords这个测试，因为不同的实现方法，也许就不需要先把句子切分成单词。

10 楼 ozzzzzz 2007-09-19  

gigix 写道

hostler 写道

ozzzzzz 写道

TDD的做法并不是要你在最早就准备好一个完整的测试系统，而是要你通过写准对需求的测试，也就是针对功能的测试，来因对性的完成你的代码。这是一个由需求，转换为针对测试，在因对的代码的过程。

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

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

其实这里就引出一个问题，也就是TDD也有粒度问题，并且很多时候这个粒度问题并不比需求中粒度问题简单，需要我们小心控制。虽说XP要求我们小步快跑，但是这个小步也是有粒度要求的。

9 楼 gigix 2007-09-19  

hostler 写道

ozzzzzz 写道

TDD的做法并不是要你在最早就准备好一个完整的测试系统，而是要你通过写准对需求的测试，也就是针对功能的测试，来因对性的完成你的代码。这是一个由需求，转换为针对测试，在因对的代码的过程。

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

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

8 楼 hostler 2007-09-19  

ozzzzzz 写道

TDD的做法并不是要你在最早就准备好一个完整的测试系统，而是要你通过写准对需求的测试，也就是针对功能的测试，来因对性的完成你的代码。这是一个由需求，转换为针对测试，在因对的代码的过程。

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

7 楼 ozzzzzz 2007-09-19  

hostler 写道

ozzzzzz 写道

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

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

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

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

6 楼 hostler 2007-09-19  

ozzzzzz 写道

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

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

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

5 楼 无明 2007-09-19  

ozzzzzz 写道

说白了测试驱动还是需求驱动，而测试则需要考虑更多的东西

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

4 楼 ozzzzzz 2007-09-19  

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

3 楼 抛出异常的爱 2007-09-19  

无明 写道

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

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

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

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

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

2 楼 无明 2007-09-19  

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

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

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

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

1 楼 taowen 2007-09-19  

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")