|
锁定老帖子 主题：测试如何驱动开发
该帖已经被评为良好帖
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2007-09-19
gigix 写道 hostler 写道 ozzzzzz 写道 TDD的做法并不是要你在最早就准备好一个完整的测试系统，而是要你通过写准对需求的测试，也就是针对功能的测试，来因对性的完成你的代码。这是一个由需求，转换为针对测试，在因对的代码的过程。
那ozzzzzz怎么看gigix 关于testShouldSplitSentenceIntoWords这个测试？ 这个测试就是所谓的“设计过程” 实际上照我真实的想法，我是不想写这个测试的，因为这个需求实在太简单了 不过为了说明这里确实有“设计”的存在…… 我把一个大的问题分解成两个小的问题，先用测试驱动解决第一个，再用测试驱动解决第二个 就是这样 其实这里就引出一个问题，也就是TDD也有粒度问题，并且很多时候这个粒度问题并不比需求中粒度问题简单，需要我们小心控制。虽说XP要求我们小步快跑，但是这个小步也是有粒度要求的。 |
| 返回顶楼 | |
|
发表时间：2007-09-19
hostler 写道 ozzzzzz 写道 TDD的做法并不是要你在最早就准备好一个完整的测试系统，而是要你通过写准对需求的测试，也就是针对功能的测试，来因对性的完成你的代码。这是一个由需求，转换为针对测试，在因对的代码的过程。
那ozzzzzz怎么看gigix 关于testShouldSplitSentenceIntoWords这个测试？ 如果从需求驱动的角度，没必要写testShouldSplitSentenceIntoWords这个测试，因为不同的实现方法，也许就不需要先把句子切分成单词。 |
| 返回顶楼 | |
|
发表时间：2007-09-19
balaschen 写道 hostler 写道 ozzzzzz 写道 TDD的做法并不是要你在最早就准备好一个完整的测试系统，而是要你通过写准对需求的测试，也就是针对功能的测试，来因对性的完成你的代码。这是一个由需求，转换为针对测试，在因对的代码的过程。
那ozzzzzz怎么看gigix 关于testShouldSplitSentenceIntoWords这个测试？ 如果从需求驱动的角度，没必要写testShouldSplitSentenceIntoWords这个测试，因为不同的实现方法，也许就不需要先把句子切分成单词。 所以我们说“TDD”。测试驱动开发，开发中的每“一步”都有测试来驱动。至于测试写到什么粒度，取决于你认为怎样的“一步”对于你来说是合适的。 |
| 返回顶楼 | |
|
发表时间：2007-09-19
其实这里又有一个问题。
那就是如果是采取TDD的方式来说明问题，那么如果把test case作为一种说明需求的工具，那么我们就需要将真正的用于测试的test case和其分开标注。 |
| 返回顶楼 | |
|
发表时间：2007-09-19
ozzzzzz 写道 其实这里又有一个问题。
那就是如果是采取TDD的方式来说明问题，那么如果把test case作为一种说明需求的工具，那么我们就需要将真正的用于测试的test case和其分开标注。 是不是说，用来驱动实现的test case，包含了设计过程，关注实现细节，但用来描述需求的test case，是不包括设计过程的，不关注实现细节，这两种test case，要明确区分？ |
| 返回顶楼 | |
|
发表时间：2007-09-19
balaschen 写道 ozzzzzz 写道 其实这里又有一个问题。
那就是如果是采取TDD的方式来说明问题，那么如果把test case作为一种说明需求的工具，那么我们就需要将真正的用于测试的test case和其分开标注。 是不是说，用来驱动实现的test case，包含了设计过程，关注实现细节，但用来描述需求的test case，是不包括设计过程的，不关注实现细节，这两种test case，要明确区分？ 其实可以这样说，你看一段代码肯定首先想知道他是做啥的。这个时候你会发现，阅读有些test case只能让你云里雾里，而阅读有些则让你马上就知道这段代码的用途。其实找并不是这些test case写的有水平差别，而往往是有针对问题角度的差别。而进一步，你会发现阅读这些test case如果按照一定顺序，就会从最初的动机到最终的实现细节都有一个清晰的理解，而如果我们能够在写这些test case的时候就标注出这个理解顺序，将是十分核算的。而实际上很多时候我们书写的顺序就是最终我们适于阅读理解的顺序。 |
| 返回顶楼 | |
|
发表时间：2007-09-20
我不太明白的是，Test2和Test3有什么不同？是不是它们的实现代码不同？
|
| 返回顶楼 | |
|
发表时间：2007-09-20
ozzzzzz 写道 测试是测试，测试驱动是测试驱动，别把两个东西搞混了。说白了测试驱动还是需求驱动，而测试则需要考虑更多的东西。gigix的做法在tdd看来很棒，但是在测试角度看则很不完整。
这样理解也说得过去，kent beck可不是这么说得。 test-driven development书中例子里还是强调了测试的complete。 gigix的需求应该细化，对空句子，最长多长的句子，要达到的性能指标。 |
| 返回顶楼 | |
|
发表时间：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));
}
|
| 返回顶楼 | |
|
发表时间：2007-09-20
要根据需求来写测试。
gigix的例子应该把需求写详细了，这样大家就明白了。 而 taowen 那个，根本就不是TDD的方式。完全就是过度需求。 例如客户只是想要一个过冬的棉袄，而且耐用就可以了。 你的测试只要保证它能过冬，而且耐用就足够了。 如果你非要给客户一个能过冬的，刀枪不入的，内置MP3，而且即使 到外太空也能使用的棉袄，那真是闲得没事干了。 |
| 返回顶楼 | |
