2007-09-18

测试如何驱动开发

需求：反转一个句子
我可能会写出以下的测试——写一个测试，然后写代码让测试通过，然后再写下一个测试。
自己看吧。 
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));  
  }  
}
评论
solospider 2007-12-29
只能说是一个没有完成的测试驱动开发的Test Case
因为仅凭这个测试用例无法完成一个完整的功能的开发
抛出异常的爱 2007-12-27
没有test1叫扩大测试颗度
也是敏捷的一种实践
我是写的
不过总是被重构掉.....
因为.....这种东西多了就遮盖了逻辑.
不写eclipse就没办法生成简单的类.
我都是对着红线点击生成类或方法的.
bookong 2007-12-27
我理解gigix的三个Test，实际上是将文字语言描述的需求翻译成测试用例描述的需求。
Test 1 对应的文字描述是“要按单词来操作一个句子”。
Test 2 对应的文字描述是“按单词反转这个句子”。
Test 3 结合Test 2 描述是“按单词反转任意一个句子”。

如果在更粗的粒度上，Test 1 感觉是可有可无的，但Test 2和Test 3反到是必须的。
不知道我理解的对不对？
blackanger 2007-10-05
[quote=gigix]满足Test2的最简单的实现是直接return预期的结果
而同时满足Test2和Test3的最简单的实现，则是我真正想要的[/quote]

kert beck 说的三角法
gigix 2007-09-30
qlqsh 写道
不好意思，新手，问一下啊。

LZ的Test2和Test3的区别在哪里？

听“抛出异常的爱”的解释似乎就是为了多测试一遍？

满足Test2的最简单的实现是直接return预期的结果
而同时满足Test2和Test3的最简单的实现，则是我真正想要的
qlqsh 2007-09-30
不好意思，新手，问一下啊。

LZ的Test2和Test3的区别在哪里？

听“抛出异常的爱”的解释似乎就是为了多测试一遍？
gigix 2007-09-25
抛出异常的爱 写道
gigix 写道
pf_miles 写道
解释得不错，只是我还有一个问题：
楼主在测试驱动过程中驱动出了一个split方法，但也许我不希望在这个提供句子反转的类里面同时暴露这个分割单词的方法，我想把它写成private的，那要怎么驱动才能避开它？直接驱动出反转功能吗？那样粒度可能就分得不好了。楼主觉得该如何做呢？

重构出一个SentenceSplitter类
不明白。。。。是哪条原则呢？

不知道是哪条原则，不过想法是这样的：
一开始我只考虑怎么实现。我设计了一个split的功能，所以我给它写测试，然后实现它。实现完以后，我发现split显然不应该是StringReverser的功能，所以我重构它，把它抽取到SentenceSplitter类，并且把对应的测试也搬到SentenceSplitterTest。这个时候StringReverser的split方法只是一句直接的delegate，所以不需要测试，并且可以直接inline到reverse方法内部去。
（以上只是为了说明过程。实际上经过重构，split这个方法非常可能被重构到只剩下“sentence.split()”这么一句，然后直接inline，然后去掉split方法和对应的测试。）
抛出异常的爱 2007-09-25
gigix 写道
pf_miles 写道
解释得不错，只是我还有一个问题：
楼主在测试驱动过程中驱动出了一个split方法，但也许我不希望在这个提供句子反转的类里面同时暴露这个分割单词的方法，我想把它写成private的，那要怎么驱动才能避开它？直接驱动出反转功能吗？那样粒度可能就分得不好了。楼主觉得该如何做呢？

重构出一个SentenceSplitter类
不明白。。。。是哪条原则呢？
gigix 2007-09-25
pf_miles 写道
解释得不错，只是我还有一个问题：
楼主在测试驱动过程中驱动出了一个split方法，但也许我不希望在这个提供句子反转的类里面同时暴露这个分割单词的方法，我想把它写成private的，那要怎么驱动才能避开它？直接驱动出反转功能吗？那样粒度可能就分得不好了。楼主觉得该如何做呢？

重构出一个SentenceSplitter类
抛出异常的爱 2007-09-25
至少应该是protected否则不太可能被测试到。。。

不过由于本人不太会写 protected 这个词
所以 都是不写前面的参数的。
如： 
 void hiddenMethod(){
//todo
}
pf_miles 2007-09-25
解释得不错，只是我还有一个问题：
楼主在测试驱动过程中驱动出了一个split方法，但也许我不希望在这个提供句子反转的类里面同时暴露这个分割单词的方法，我想把它写成private的，那要怎么驱动才能避开它？直接驱动出反转功能吗？那样粒度可能就分得不好了。楼主觉得该如何做呢？
ozzzzzz 2007-09-23
taowen 写道
yananay 写道
要根据需求来写测试。
gigix的例子应该把需求写详细了，这样大家就明白了。

而 taowen 那个，根本就不是TDD的方式。完全就是过度需求。

例如客户只是想要一个过冬的棉袄，而且耐用就可以了。
你的测试只要保证它能过冬，而且耐用就足够了。

如果你非要给客户一个能过冬的，刀枪不入的，内置MP3，而且即使
到外太空也能使用的棉袄，那真是闲得没事干了。

是不是过度需求，取决于用户。反转字符串这种库级别的方法，能够处理null和空白是很正常的需求。如果有这样的需求的话，我绝对是现写最简单的边界条件的。如果几个测试最后走的都是同一个路径的话，我在写的时候就会把他们合并掉或者删掉没有必要的那个的。

合并和删除一个测试要比添加困难的多，资源消耗也大的多。
taowen 2007-09-22
yananay 写道
要根据需求来写测试。
gigix的例子应该把需求写详细了，这样大家就明白了。

而 taowen 那个，根本就不是TDD的方式。完全就是过度需求。

例如客户只是想要一个过冬的棉袄，而且耐用就可以了。
你的测试只要保证它能过冬，而且耐用就足够了。

如果你非要给客户一个能过冬的，刀枪不入的，内置MP3，而且即使
到外太空也能使用的棉袄，那真是闲得没事干了。

是不是过度需求，取决于用户。反转字符串这种库级别的方法，能够处理null和空白是很正常的需求。如果有这样的需求的话，我绝对是现写最简单的边界条件的。如果几个测试最后走的都是同一个路径的话，我在写的时候就会把他们合并掉或者删掉没有必要的那个的。
bluse 2007-09-21
我感觉还是gigix的算是TDD吧，testShouldSplitSentenceIntoWords测试方法是他实现所需要的
抛出异常的爱 2007-09-21
yananay 写道
要根据需求来写测试。
gigix的例子应该把需求写详细了，这样大家就明白了。

而 taowen 那个，根本就不是TDD的方式。完全就是过度需求。

例如客户只是想要一个过冬的棉袄，而且耐用就可以了。
你的测试只要保证它能过冬，而且耐用就足够了。

如果你非要给客户一个能过冬的，刀枪不入的，内置MP3，而且即使
到外太空也能使用的棉袄，那真是闲得没事干了。


也客户可能要的就是这个
只是现在没提，
那么现在就不要作
反正tdd的好处就是改起来没负担，快。
只有有了需求再改。。。成这个样子。
yananay 2007-09-20
要根据需求来写测试。
gigix的例子应该把需求写详细了，这样大家就明白了。

而 taowen 那个，根本就不是TDD的方式。完全就是过度需求。

例如客户只是想要一个过冬的棉袄，而且耐用就可以了。
你的测试只要保证它能过冬，而且耐用就足够了。

如果你非要给客户一个能过冬的，刀枪不入的，内置MP3，而且即使
到外太空也能使用的棉袄，那真是闲得没事干了。
抛出异常的爱 2007-09-20
hlxiong 写道
我不太明白的是，Test2和Test3有什么不同？是不是它们的实现代码不同？

是啊
test2的代码可以写成：return "XXXXXXXXxx xxxxxxxxXXXXXX";
test3的代码必须写成：用截取的方式。
抛出异常的爱 写道
第一步的写法 
	
     /**
      *测试：
      */
       public void testReverseOne(){  
        StringReverser sr=new StringReverser();  
        String str = "abc";  
       Assert.assertEquals("abc",sr.reverse(str));  
  }  

	//代码
       public Object reverse(String str) {
		return "abc";
	}

第二步的写法 
	 
        /**
         *测试：
         */
        public void testReverseOne(){  
        StringReverser sr=new StringReverser();  
        String str = "abc";  
       Assert.assertEquals("abc",sr.reverse(str));  
  }  
        /**
         *新加测试：
         */
        public void testReverseTwo(){  
        StringReverser sr=new StringReverser();  
        String str = "abc def";  
       Assert.assertEquals("def abc",sr.reverse(str));  
  }  

  
        /**
         * 为了完成功能。。。
         */
          public Object reverse(String str) {
		String [] tmp = str.split(" ");//坏味道
		str ="";//坏味道
		for(int i = tmp.length ;i >0 ; i--){//坏味道
			str += tmp[i-1];//坏味道
			str+=" ";//坏味道
		}
		return str.trim();//坏味道
	}

第三步重构：
。。。。。。。。。。。。
这就看个人功力了。

我对自己不太信任所以还会写第三个测试。。。 
	public void testReverseThree(){  
        StringReverser sr=new StringReverser();  
        String str = "abc def gh";  
       Assert.assertEquals("gh def abc",sr.reverse(str));  
  }

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

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

gigix的需求应该细化，对空句子，最长多长的句子，要达到的性能指标。
hlxiong 2007-09-20
我不太明白的是，Test2和Test3有什么不同？是不是它们的实现代码不同？
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的时候就标注出这个理解顺序，将是十分核算的。而实际上很多时候我们书写的顺序就是最终我们适于阅读理解的顺序。
发表评论

提醒: 该博客已发表在公共论坛，博客所有留言会成为论坛回贴，留言请注意遵守论坛发贴规则

您还没有登录，请登录后发表评论

gigix
搜索本博客
最近加入圈子
存档
最新评论