微信扫一扫1240
社区成员
关于TDD过程中如何让文档同步。
这个问题，后来感觉似乎放在这个板块似乎不大合适，不过这里的讨论我更喜欢些，所以还是放到这里了，希望o6z别“砍”我，我发现0分的帖子讨论的人更积极些也更纯粹些。
我在实践TDD的过程中，一直有这样的疑问和麻烦在困扰我，首先，这里说的文档主要还是JAVADOC文档，抛开其它的从to do list开始的TDD的实践，我们知道，TDD总是秉承这样的迭代（细节不必细扣）：
Add a little test.
Run all tests and fail.
Make a change.
Run the tests and succeed.
Refactor to remove duplication.
在这个过程中，我们看到，设计是很容易改变的，设计总是在随测试用例的添加不断更新，在完成一次迭代的最后一步重构中，更是可能会产生翻天覆地的变化（注：这里当然如果熟练，一开始就有好的框架和设计总是可能的，不过按照拥抱变化的原则，翻天覆地的变化也并非不可能），这个中间必然有一个JAVADOC文档同步的问题。
大多数人会选择先写JAVADOC文档，而后再修改代码，但是这个工作量仍然是很大的，可能超出自己能忍受的范围，为什么呢？考虑这样的状况，为了保证迭代的持续性，我们通常采用自己所能控制的最小步骤来进行重构（或者开发，为了好说明，我后面就只说重构的状况下，因为相对普遍些，也省力点），这样，一个方法甚至一个类，它可能只是我整个重构完成后的一个中间过程，比如对于a方法，第一次重构中产生了它，接着第三次重构中我把它去掉了，然后，很可能在后面的又一次重构过程中它又回来了，而且随着重构的深入，可能a这个方法的意义也在进行演化。
我相信，在一小组重构（多次小重构组成）开始时我们大脑里面是有一个大概的目标的，但是这个目标可能并不是那么明确的，因为毕竟还没有实现的，我们总是不好说一定会这样，如果一定会，那么这一小组重构就没有必要细分多次小重构了。
好了，现在问题出来了，由于a方法的反复，我们如果仍然在每次重构a前先写JAVADOC文档，就会出现很多看起来似乎很多余的动作，不断地删除（当然，你可以只是注释掉它）又加回来，然后还要一点一点记录a方法本身的演化过程，很多中间过程在最终结果看来似乎价值不大，注意，这个过程中代码的反复添加删除修改在工具的支持下反而代价极小，所以，虽然是一组重构，但是其实完整这一小组重构花的时间并不多。
我们是在每次重构前都不厌其烦地停下来修改JAVADOC文档先呢（这样做让重构的时间成本翻好几倍可能）？还是很快地完成了这一小组重构再去修改呢？又或者，一开始就按这一小组重构目标所规划地来再必要的地方先加好JAVADOC文档（这个，好像不太好，^_^）？
上面这个问题在你熟练重构和设计状况下还好些，出现的可能并不大，还有一种重构，在设计中，突然你发现需要改动框架了，这个时候，问题就比较严重了，比如你需要在一个顶级接口中添加一个方法，或者根本是要让顶级接口的方法有一个全新的面貌，这个时候的重构可能做不到一蹴而就，而是一点一点地修正，同时还可能要重构很多的unit test，这个时候，是满世界去修改JAVADOC文档先呢？还是利用工具的优势，让代码很快地修正？老实说，这个诱惑还是很大的，因为我们总是想在最早的时间让所有测试通过的。很多时候会这样，测试都通过了，然后，呼一口气，心里想看来程序是按照自己的想法在跑了，然后一点一点地修正所有的JAVADOC文档。如果反过来，开始修改JAVADOC文档，似乎很容易中断自己的思路，因为好像是要把设计翻译成中文一样。
之所以会有这样的困扰，主要是在《测试驱动开发》中，一路跑下去，没有关于JAVADOC文档的内容，从头到尾提倡：多跑测试，让重构和变化在自己控制范围内产生，以使所有测试能在大多数时间内都是通过的，如果有不通过的，也要在第一时间让其通过先（这个重点），而使用重构来改善代码结构（在需要一个新方法时，总是让这个方法返回一个写死的预期值来满足当前测试，然后在重构中完善它，这一点我印象非常深刻）。
不知道大家都是怎么处理这个问题的。
另一个是unit test的javadoc文档应该如何写，看JUnit代码，其中测试用例的javadoc几乎没有，反而存在不少非javadoc的注释；通常我会把to do list放进去，但是现在看来这样做并不是很好的选择，因为当需求膨胀的时候，to do list也会膨胀地离谱而难以维护，这一点也请有实践经验的朋友谈一谈。
我在实践TDD的过程中，一直有这样的疑问和麻烦在困扰我，首先，这里说的文档主要还是JAVADOC文档，抛开其它的从to do list开始的TDD的实践，我们知道，TDD总是秉承这样的迭代（细节不必细扣）：
Add a little test.
Run all tests and fail.
Make a change.
Run the tests and succeed.
Refactor to remove duplication.
在这个过程中，我们看到，设计是很容易改变的，设计总是在随测试用例的添加不断更新，在完成一次迭代的最后一步重构中，更是可能会产生翻天覆地的变化（注：这里当然如果熟练，一开始就有好的框架和设计总是可能的，不过按照拥抱变化的原则，翻天覆地的变化也并非不可能），这个中间必然有一个JAVADOC文档同步的问题。
大多数人会选择先写JAVADOC文档，而后再修改代码，但是这个工作量仍然是很大的，可能超出自己能忍受的范围，为什么呢？考虑这样的状况，为了保证迭代的持续性，我们通常采用自己所能控制的最小步骤来进行重构（或者开发，为了好说明，我后面就只说重构的状况下，因为相对普遍些，也省力点），这样，一个方法甚至一个类，它可能只是我整个重构完成后的一个中间过程，比如对于a方法，第一次重构中产生了它，接着第三次重构中我把它去掉了，然后，很可能在后面的又一次重构过程中它又回来了，而且随着重构的深入，可能a这个方法的意义也在进行演化。
我相信，在一小组重构（多次小重构组成）开始时我们大脑里面是有一个大概的目标的，但是这个目标可能并不是那么明确的，因为毕竟还没有实现的，我们总是不好说一定会这样，如果一定会，那么这一小组重构就没有必要细分多次小重构了。
好了，现在问题出来了，由于a方法的反复，我们如果仍然在每次重构a前先写JAVADOC文档，就会出现很多看起来似乎很多余的动作，不断地删除（当然，你可以只是注释掉它）又加回来，然后还要一点一点记录a方法本身的演化过程，很多中间过程在最终结果看来似乎价值不大，注意，这个过程中代码的反复添加删除修改在工具的支持下反而代价极小，所以，虽然是一组重构，但是其实完整这一小组重构花的时间并不多。
我们是在每次重构前都不厌其烦地停下来修改JAVADOC文档先呢（这样做让重构的时间成本翻好几倍可能）？还是很快地完成了这一小组重构再去修改呢？又或者，一开始就按这一小组重构目标所规划地来再必要的地方先加好JAVADOC文档（这个，好像不太好，^_^）？
上面这个问题在你熟练重构和设计状况下还好些，出现的可能并不大，还有一种重构，在设计中，突然你发现需要改动框架了，这个时候，问题就比较严重了，比如你需要在一个顶级接口中添加一个方法，或者根本是要让顶级接口的方法有一个全新的面貌，这个时候的重构可能做不到一蹴而就，而是一点一点地修正，同时还可能要重构很多的unit test，这个时候，是满世界去修改JAVADOC文档先呢？还是利用工具的优势，让代码很快地修正？老实说，这个诱惑还是很大的，因为我们总是想在最早的时间让所有测试通过的。很多时候会这样，测试都通过了，然后，呼一口气，心里想看来程序是按照自己的想法在跑了，然后一点一点地修正所有的JAVADOC文档。如果反过来，开始修改JAVADOC文档，似乎很容易中断自己的思路，因为好像是要把设计翻译成中文一样。
之所以会有这样的困扰，主要是在《测试驱动开发》中，一路跑下去，没有关于JAVADOC文档的内容，从头到尾提倡：多跑测试，让重构和变化在自己控制范围内产生，以使所有测试能在大多数时间内都是通过的，如果有不通过的，也要在第一时间让其通过先（这个重点），而使用重构来改善代码结构（在需要一个新方法时，总是让这个方法返回一个写死的预期值来满足当前测试，然后在重构中完善它，这一点我印象非常深刻）。
不知道大家都是怎么处理这个问题的。
另一个是unit test的javadoc文档应该如何写，看JUnit代码，其中测试用例的javadoc几乎没有，反而存在不少非javadoc的注释；通常我会把to do list放进去，但是现在看来这样做并不是很好的选择，因为当需求膨胀的时候，to do list也会膨胀地离谱而难以维护，这一点也请有实践经验的朋友谈一谈。
...全文
当前发帖距今超过3年，不再开放新的回复
发表回复
BirdGu 2004-02-03
我认为TDD是在做一个具体的任务时采取的策略，这个任务应该是能在几小时内，最多一、两天内能完成。而这样的任务的需求应该是根据设计的结果，实现一个类。这个设计可能是通过CRC或是简单的UML图表现的。当然这只是一个对这个对象担负什么职责的大致概念，对实现的细节和接口的细节并不最后确定，甚至没有详细的描述，这些需要在TDD的过程中加以细化。因此不能说有了目标对象，TestCase就只是验证“目标对象是不是符合自己的需求了”。当然在开发过程中也可能会对最初的考虑加以修正，以及增加其它对象。你怎么考虑CRC Session或是其它设计活动与TDD的关系呢？
对于在实现过程中增加其它对象一点，可能符合你说的：由测试用例的完成倒推出来我们需要什么样的对象。
当设计一个大框架，特别是多个人合作时，更是需要对框架有个初步的设计，甚至象o6z说的那样对一些接口做比较详细的规定，否则如何分配任务，和协调多个人的合作呢？但这个TDD是两个层面上的事情。
对于在实现过程中增加其它对象一点，可能符合你说的：由测试用例的完成倒推出来我们需要什么样的对象。
当设计一个大框架，特别是多个人合作时，更是需要对框架有个初步的设计，甚至象o6z说的那样对一些接口做比较详细的规定，否则如何分配任务，和协调多个人的合作呢？但这个TDD是两个层面上的事情。
- 打赏
- 举报
ozzzzzz 2004-02-03
swinging(山不在高)
你看书好像太抠字眼了，看来我还是要继续解释我的做法。
作为一个多人参加的项目，提前进行一下设计是必须的。虽然XP提出尽早的进行编码，但是我不认为，XP是在说，你应该一开始就进行编码。首先我们知道XP的过程是从写USER STORY开始的，而对于USER STORY我们不仅要知道它代表了什么，还要知道它的条件是什么，也就是要考虑它是不是要求以实在某些别的任务为前提。而实际上究竟是不是在userstory作为任务进行分配，还是要看你是不是把那些userstory做了很好的粒度划分。我一般建议大家还是把userstory近一步划分为task卡，这样的好处是可以在早期就发现各个userstory间会共有的那些部分。而XP强调尽早的进行编码只是说设计应该是一种高层的设计，而不是细节化的设计。
作为TDD一样是这个问题，如果你只是考虑自己一个人，完全可以在开始的时候就不需要规范那些接口的javadoc。但是当你是在一个组织内部的时候，这样的情况往往很难实施。不过我认为那些针对接口的javadoc只是在起到部分的作用，是为了别人可以更快速的去理解他要使用的接口，不要把这个东西过分的细节化，只是做到可以理解梗概就可以了。真正的保持接口的定义被尊重是应该写真正的单元测试来解决的。而这也说明javadoc未必就不是一种味道，它也是在初期表明你需要对那些地方做测试。只不过这些东西是可以做到很梗概的，所以对其维护的也可以不会花费太高的成本，而且其可以直接在最好生产出代码说明文档，这个文档往往是最后项目必须提交给客户的一个部分，所以我才会保留它。而且我也会把这些注释使用单独的颜色，作为我在代码中寻找公开接口的地方。嘿嘿，我觉得使用这个方法，比去搜索public方便点。
你看书好像太抠字眼了，看来我还是要继续解释我的做法。
作为一个多人参加的项目，提前进行一下设计是必须的。虽然XP提出尽早的进行编码，但是我不认为，XP是在说，你应该一开始就进行编码。首先我们知道XP的过程是从写USER STORY开始的，而对于USER STORY我们不仅要知道它代表了什么，还要知道它的条件是什么，也就是要考虑它是不是要求以实在某些别的任务为前提。而实际上究竟是不是在userstory作为任务进行分配，还是要看你是不是把那些userstory做了很好的粒度划分。我一般建议大家还是把userstory近一步划分为task卡，这样的好处是可以在早期就发现各个userstory间会共有的那些部分。而XP强调尽早的进行编码只是说设计应该是一种高层的设计，而不是细节化的设计。
作为TDD一样是这个问题，如果你只是考虑自己一个人，完全可以在开始的时候就不需要规范那些接口的javadoc。但是当你是在一个组织内部的时候，这样的情况往往很难实施。不过我认为那些针对接口的javadoc只是在起到部分的作用，是为了别人可以更快速的去理解他要使用的接口，不要把这个东西过分的细节化，只是做到可以理解梗概就可以了。真正的保持接口的定义被尊重是应该写真正的单元测试来解决的。而这也说明javadoc未必就不是一种味道，它也是在初期表明你需要对那些地方做测试。只不过这些东西是可以做到很梗概的，所以对其维护的也可以不会花费太高的成本，而且其可以直接在最好生产出代码说明文档，这个文档往往是最后项目必须提交给客户的一个部分，所以我才会保留它。而且我也会把这些注释使用单独的颜色，作为我在代码中寻找公开接口的地方。嘿嘿，我觉得使用这个方法，比去搜索public方便点。
- 打赏
- 举报
BirdGu 2004-02-02
我的意思是说在写TestCase的时候我们已经知道需要什么对象了，这个对象就是我们测试的目标，我们知道需要这个对象做什么，但对它怎么做还不是很清楚。
- 打赏
- 举报
swinging 2004-02-02
哦。
我是这样认为的，如果想测试什么，知道了以后然后想这个东西是怎么来的。
而如果想有什么对象好测试的，然后说，哦，我有这样一个对象需要测试，测试需要这样进行，于是写下了代码，
一样吗？不同。
当你想到“有这样一个对象需要测试”时，这个时候，你其实已经假设自己完成了设计，因为目标对象已经出现了，接下来的TEST CASE，只是验证下你想到的目标对象是不是符合自己的需求了。
而先想测试什么，则恰恰相反，它是由测试用例的完成倒推出来我们需要什么样的对象，
等你完成了test case，会说，哦，原来需要这样的一个对象。这个过程是实实在在反映出，在写TEST CASE过程中我们是如何一步一步构造出来我们需求所需要的目标对象的，而不像前面那种，一股脑想出来一个目标，然后再看看这个目标是不是我们所需要的对象。
在构筑小东西的时候，两个过程确实是几乎一样，但是当目标是一个大的框架时，就会很不同了。
当然，也许你也是这个意思，是我领会错了。^_^
我是这样认为的，如果想测试什么，知道了以后然后想这个东西是怎么来的。
而如果想有什么对象好测试的，然后说，哦，我有这样一个对象需要测试，测试需要这样进行，于是写下了代码，
一样吗？不同。
当你想到“有这样一个对象需要测试”时，这个时候，你其实已经假设自己完成了设计，因为目标对象已经出现了，接下来的TEST CASE，只是验证下你想到的目标对象是不是符合自己的需求了。
而先想测试什么，则恰恰相反，它是由测试用例的完成倒推出来我们需要什么样的对象，
等你完成了test case，会说，哦，原来需要这样的一个对象。这个过程是实实在在反映出，在写TEST CASE过程中我们是如何一步一步构造出来我们需求所需要的目标对象的，而不像前面那种，一股脑想出来一个目标，然后再看看这个目标是不是我们所需要的对象。
在构筑小东西的时候，两个过程确实是几乎一样，但是当目标是一个大的框架时，就会很不同了。
当然，也许你也是这个意思，是我领会错了。^_^
- 打赏
- 举报
BirdGu 2004-02-02
既然写测试的时候已经知道我们需要怎么样的接口，那这是什么东西的接口呢？它必然是某个对象的接口嘛。
不过我觉得我们并没有本质上的分歧，可能只是对一些具体文字和语句的表述上有所不同。
不过我觉得我们并没有本质上的分歧，可能只是对一些具体文字和语句的表述上有所不同。
- 打赏
- 举报
swinging 2004-02-02
哦，不过TDD的TEST FIRST是不赞成这样的，《测试驱动开发》part 1 chapter1专门有一段说这个的（为了方便我就摘下来吧）：
When we write a test, we imagine the perfect interface for our operation. We are telling ourselves a story about how the operation will look from the outside. Our story won't always come true, but it's better to start from the best-possible application program interface (API) and work backward than to make things complicated, ugly, and "realistic" from the get-go.
我觉得在写test case前完全不考虑我们需要什么样的对象，正是tdd的特点，它让你考虑你需要一个什么样的目标操作（测试的就是这个操作），或者说你希望什么样的操作接口来满足你的需求，
然后再由这些东西组成目标的对象，如果可能你可以任意地通过重构来获得更好的设计，而不是局限于预先想象的目标对象。
其实看《测试驱动开发》中给我们演示的写test case的过程就知道，如下的test case：
public void testMultiplication() {
Dollar five= new Dollar(5);
five.times(2);
assertEquals(10, five.amount);
}
它是怎么写出来呢，第一步是写：
assertEquals(10, five.amount);
出来都是错误，没有关系，
然后根据需要把前面的补齐：
Dollar five= new Dollar(5);
five.times(2);
最后为了让程序编译通过，你还需要建立一个Dollar类，再......
这个过程在书中有准确地说明（忘了哪里呢，sweat），
而且在书后面的pattern里面，有专门说明tdd的一些开发模式，
其中一个就是：assert first。
这里说明的是，现在讨论的前提都是tdd，所以会引用《测试驱动开发》原文的内容，
我觉得这样有说服力一些，
我自己的实践过程中，也确实是感觉到这样做的很多好处，不过就像本贴讨论的一样，
很多东西我还是有疑问的。
When we write a test, we imagine the perfect interface for our operation. We are telling ourselves a story about how the operation will look from the outside. Our story won't always come true, but it's better to start from the best-possible application program interface (API) and work backward than to make things complicated, ugly, and "realistic" from the get-go.
我觉得在写test case前完全不考虑我们需要什么样的对象，正是tdd的特点，它让你考虑你需要一个什么样的目标操作（测试的就是这个操作），或者说你希望什么样的操作接口来满足你的需求，
然后再由这些东西组成目标的对象，如果可能你可以任意地通过重构来获得更好的设计，而不是局限于预先想象的目标对象。
其实看《测试驱动开发》中给我们演示的写test case的过程就知道，如下的test case：
public void testMultiplication() {
Dollar five= new Dollar(5);
five.times(2);
assertEquals(10, five.amount);
}
它是怎么写出来呢，第一步是写：
assertEquals(10, five.amount);
出来都是错误，没有关系，
然后根据需要把前面的补齐：
Dollar five= new Dollar(5);
five.times(2);
最后为了让程序编译通过，你还需要建立一个Dollar类，再......
这个过程在书中有准确地说明（忘了哪里呢，sweat），
而且在书后面的pattern里面，有专门说明tdd的一些开发模式，
其中一个就是：assert first。
这里说明的是，现在讨论的前提都是tdd，所以会引用《测试驱动开发》原文的内容，
我觉得这样有说服力一些，
我自己的实践过程中，也确实是感觉到这样做的很多好处，不过就像本贴讨论的一样，
很多东西我还是有疑问的。
- 打赏
- 举报
swinging 2004-02-01
首先，楼上这句：说写TestCase的时候考虑的是“What object do we need first？”这恐怕有问题。如果连需要测试的对象是什么东西都不知道，这个测试恐怕没法写。
前后矛盾，是不是说的：说写TestCase的时候考虑的是“What test do we need first？”这恐怕有问题。如果连需要测试的对象是什么东西都不知道，这个测试恐怕没法写。
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
“在一开始就确定各自的接口这是一种良好的习惯，编写代码现在应该是一种集体行为，需要考虑协作，表现就是确定互相的接口。”
这句话看来是没什么问题，我也赞同，但是，其实O6z你隐藏其问题，那就是“确定各自的接口”中这个“接口”的范围和深度，
注：“接口”一词，以下都是指抽象的概念。
其实瀑布模型也是这样做的，但是现在已经有很多理由认为它不合适了，它在需求分析至详细设计都要求对系统的“接口”的确定的范围要最广（达到目标系统要求至少）、深度最深（一直细化至方法、属性），这个在现在看来，当需求变化反复和难以确定的时候几乎不可能达到（几乎到可以说完全了吧大概）。
当然，这里说瀑布，只是举极端的例子说明，我本人其实对瀑布模型没有深入的研究，说的不大对的地方别扣我。
相同道理，o6z你认为在系统迭代开始前的对“接口”的确定要达到怎样的广度和深度呢？
这一点是我想学习的，不是质问，更不是拿来和我举的例子比。
我前面也说了，并不是说，开始代码前什么都不作的。
XP的规则，在设计级有如下这些（我拷贝过来的，^_^）：
Designing
Simplicity.
Choose a system metaphor.
Use CRC cards for design sessions.
Create spike solutions to reduce risk.
No functionality is added early.
Refactor whenever and wherever possible.
其中“Simplicity.”和“No functionality is added early”基本限定了在设计阶段对“接口”定义和设计的广度和深度。就看个人和团队怎么理解和运用了，不过这里我想到的又是《测试驱动开发》一书中提到的关于每次小步前进的策略，它并不限定到底这一小步的跨度有多大，而是要实践者自己来给自己定制，也许你一小步跨出了1米，但是我也可以一小步只跨出1厘米，如果我觉得合适，我也可以一小步跨出10米去；所以我想，XP不但拥抱需求变化，也拥抱开发环境、团队等等各种因素的变化，每个团队在应用它时是需要进行量身定做的。（似乎跑题，sweat）
我的问题是，虽然说可以定制设计策略，但是有没有必要达到清楚每个类和方法这样的广度和深度？如果是这样的广度和深度，所有都已经在你的test case开始前就确定了的，即使是你写代码的时候先写test case，那也不过是走个形式罢了，和先写开发代码没有本质的区别的，难道能是测试先行吗？
这里再次声明的是，我并没有说test case前没有任何考虑，XP的设计策略应该和tdd并不冲突，因为它们之间其实是承上启下的，而o6z你所说的设计，基本已经是一步到位了的。
我并不是说这样做不对，至少在我接触TDD前，几乎所有的包括书啊、实践啊、什么经验啊等等等等都告诉我，在开始代码前如果在纸上（或者说设计模型上）让系统跑起来满足当前迭代的基本需求，那么再开始编码才是合理的，这样做对系统的把握大些，返工的可能和量也小些；但就是TDD的开发思想完全扭转了我的观念，也让我更理解XP的设计策略为什么第一条就是“Simplicity”。
不过话说回来，实际可能很复杂，很多情况其实没有对与错，比如对开发框架的初次迭代而且仅仅是框架，我想设计会相对其它情况详细很多，不过，我仍然觉得，没有必要也不应该细致到所有类和方法这样的级别。
还有这种状况可能，就是，你认为我的简单设计已经是你的一个迭代开发周期，就是说，如果一个迭代开发周期缩小到尽可能的小，小到足以让设计阶段的广度和深度完全覆盖TDD；真的会这样吗？我觉得不是，设计策略说“Simplicity”，我想更多的是指对原始系统的抽象，而不是指设计本身。
说到“系统隐寓”，简单的解释大概是：Choose a system metaphor to keep the team on the same page by naming classes and methods consistently.
“可以认为它是框架的简单抽象。”，感觉也很像数据字典起的作用。
不过，我觉得它更贴近原始系统（就是现实世界的系统，区别于我们要使用计算机构筑的系统，暂时用这个词吧）一些，在设计和原始系统间建立一个简单的桥梁。
（怎么觉得越说越远了，看来还是过段时间再回来讨论先，^_^）
前后矛盾，是不是说的：说写TestCase的时候考虑的是“What test do we need first？”这恐怕有问题。如果连需要测试的对象是什么东西都不知道，这个测试恐怕没法写。
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
“在一开始就确定各自的接口这是一种良好的习惯，编写代码现在应该是一种集体行为，需要考虑协作，表现就是确定互相的接口。”
这句话看来是没什么问题，我也赞同，但是，其实O6z你隐藏其问题，那就是“确定各自的接口”中这个“接口”的范围和深度，
注：“接口”一词，以下都是指抽象的概念。
其实瀑布模型也是这样做的，但是现在已经有很多理由认为它不合适了，它在需求分析至详细设计都要求对系统的“接口”的确定的范围要最广（达到目标系统要求至少）、深度最深（一直细化至方法、属性），这个在现在看来，当需求变化反复和难以确定的时候几乎不可能达到（几乎到可以说完全了吧大概）。
当然，这里说瀑布，只是举极端的例子说明，我本人其实对瀑布模型没有深入的研究，说的不大对的地方别扣我。
相同道理，o6z你认为在系统迭代开始前的对“接口”的确定要达到怎样的广度和深度呢？
这一点是我想学习的，不是质问，更不是拿来和我举的例子比。
我前面也说了，并不是说，开始代码前什么都不作的。
XP的规则，在设计级有如下这些（我拷贝过来的，^_^）：
Designing
Simplicity.
Choose a system metaphor.
Use CRC cards for design sessions.
Create spike solutions to reduce risk.
No functionality is added early.
Refactor whenever and wherever possible.
其中“Simplicity.”和“No functionality is added early”基本限定了在设计阶段对“接口”定义和设计的广度和深度。就看个人和团队怎么理解和运用了，不过这里我想到的又是《测试驱动开发》一书中提到的关于每次小步前进的策略，它并不限定到底这一小步的跨度有多大，而是要实践者自己来给自己定制，也许你一小步跨出了1米，但是我也可以一小步只跨出1厘米，如果我觉得合适，我也可以一小步跨出10米去；所以我想，XP不但拥抱需求变化，也拥抱开发环境、团队等等各种因素的变化，每个团队在应用它时是需要进行量身定做的。（似乎跑题，sweat）
我的问题是，虽然说可以定制设计策略，但是有没有必要达到清楚每个类和方法这样的广度和深度？如果是这样的广度和深度，所有都已经在你的test case开始前就确定了的，即使是你写代码的时候先写test case，那也不过是走个形式罢了，和先写开发代码没有本质的区别的，难道能是测试先行吗？
这里再次声明的是，我并没有说test case前没有任何考虑，XP的设计策略应该和tdd并不冲突，因为它们之间其实是承上启下的，而o6z你所说的设计，基本已经是一步到位了的。
我并不是说这样做不对，至少在我接触TDD前，几乎所有的包括书啊、实践啊、什么经验啊等等等等都告诉我，在开始代码前如果在纸上（或者说设计模型上）让系统跑起来满足当前迭代的基本需求，那么再开始编码才是合理的，这样做对系统的把握大些，返工的可能和量也小些；但就是TDD的开发思想完全扭转了我的观念，也让我更理解XP的设计策略为什么第一条就是“Simplicity”。
不过话说回来，实际可能很复杂，很多情况其实没有对与错，比如对开发框架的初次迭代而且仅仅是框架，我想设计会相对其它情况详细很多，不过，我仍然觉得，没有必要也不应该细致到所有类和方法这样的级别。
还有这种状况可能，就是，你认为我的简单设计已经是你的一个迭代开发周期，就是说，如果一个迭代开发周期缩小到尽可能的小，小到足以让设计阶段的广度和深度完全覆盖TDD；真的会这样吗？我觉得不是，设计策略说“Simplicity”，我想更多的是指对原始系统的抽象，而不是指设计本身。
说到“系统隐寓”，简单的解释大概是：Choose a system metaphor to keep the team on the same page by naming classes and methods consistently.
“可以认为它是框架的简单抽象。”，感觉也很像数据字典起的作用。
不过，我觉得它更贴近原始系统（就是现实世界的系统，区别于我们要使用计算机构筑的系统，暂时用这个词吧）一些，在设计和原始系统间建立一个简单的桥梁。
（怎么觉得越说越远了，看来还是过段时间再回来讨论先，^_^）
- 打赏
- 举报
BirdGu 2004-02-01
TDD中的TestCase究竟是需求还是设计呢？可以说即是需求，也是设计。
TestCase描述的是对系统某一模块的需求，即这一模块需要提供怎样的接口，完成怎样的功能。那么模块的功能划分和接口定义不就是设计吗？
说写TestCase的时候考虑的是“What object do we need first？”这恐怕有问题。如果连需要测试的对象是什么东西都不知道，这个测试恐怕没法写。当然要测试的对象是否还需要其它对象来协同完成任务，这是属于“如何通过测试”这个问题的范畴。
TestCase描述的是对系统某一模块的需求，即这一模块需要提供怎样的接口，完成怎样的功能。那么模块的功能划分和接口定义不就是设计吗？
说写TestCase的时候考虑的是“What object do we need first？”这恐怕有问题。如果连需要测试的对象是什么东西都不知道，这个测试恐怕没法写。当然要测试的对象是否还需要其它对象来协同完成任务，这是属于“如何通过测试”这个问题的范畴。
- 打赏
- 举报
ozzzzzz 2004-02-01
swinging(山不在高)
在一开始就确定各自的接口这是一种良好的习惯，编写代码现在应该是一种集体行为，需要考虑协作，表现就是确定互相的接口。而在一开始，并不是说在项目的开始阶段，而是在这个迭代的开始阶段。代码就是设计，不能就认为我们就不需要先考虑一下，有一下大概的思路，做好互相间的协调，让大家都知道各自该干什么。为什么要在开始有一个统一的认识（其实这也就是对于设计的review），就是让大家知道自己在系统中的位置，同时明白系统的运作原理。你看xp可以看到一个说法－－系统隐寓，他的作用就是让参与者理解系统的运作原理，可以认为它是框架的简单抽象。
tdd的方式在我看来没有什么特别的，并不是真的测试之前就没有任何东西。你至少应该知道你要做什么，要测试什么。其实测试优先就是给一个手段把你的设计提前形式化、具体化，从而增加可见度，并且有强制的约束性。
在一开始就确定各自的接口这是一种良好的习惯，编写代码现在应该是一种集体行为，需要考虑协作，表现就是确定互相的接口。而在一开始，并不是说在项目的开始阶段，而是在这个迭代的开始阶段。代码就是设计，不能就认为我们就不需要先考虑一下，有一下大概的思路，做好互相间的协调，让大家都知道各自该干什么。为什么要在开始有一个统一的认识（其实这也就是对于设计的review），就是让大家知道自己在系统中的位置，同时明白系统的运作原理。你看xp可以看到一个说法－－系统隐寓，他的作用就是让参与者理解系统的运作原理，可以认为它是框架的简单抽象。
tdd的方式在我看来没有什么特别的，并不是真的测试之前就没有任何东西。你至少应该知道你要做什么，要测试什么。其实测试优先就是给一个手段把你的设计提前形式化、具体化，从而增加可见度，并且有强制的约束性。
- 打赏
- 举报
swinging 2004-02-01
啊？
这句：说写TestCase的时候考虑的是“What object do we need first？”这恐怕有问题。如果连需要测试的对象是什么东西都不知道，这个测试恐怕没法写。
前面的“说写TestCase的时候考虑的是“What object do we need first？”这恐怕有问题”，这个意思应该是说写TestCase的考虑What object do we need first？是有问题的，就是说不应该考虑What object do we need first？，
可是后面一句：如果连需要测试的对象是什么东西都不知道，这个测试恐怕没法写。
应该意思是，如果不知道“需要测试的对象”，那么test case无法写，也就是说，应该在写test case时考虑What object do we need first？，
这样的话，不是矛盾吗？
这句：说写TestCase的时候考虑的是“What object do we need first？”这恐怕有问题。如果连需要测试的对象是什么东西都不知道，这个测试恐怕没法写。
前面的“说写TestCase的时候考虑的是“What object do we need first？”这恐怕有问题”，这个意思应该是说写TestCase的考虑What object do we need first？是有问题的，就是说不应该考虑What object do we need first？，
可是后面一句：如果连需要测试的对象是什么东西都不知道，这个测试恐怕没法写。
应该意思是，如果不知道“需要测试的对象”，那么test case无法写，也就是说，应该在写test case时考虑What object do we need first？，
这样的话，不是矛盾吗？
- 打赏
- 举报
BirdGu 2004-02-01
swinging(山不在高)：我的话没有错，你别乱改。又哪里有矛盾了？
- 打赏
- 举报
swinging 2004-02-01
回BirdGu(鲲鹏) && Schlemiel(维特根斯坦的扇子)
sorry，看来我随便带出来的话又模糊了。
通常我想是这样的，to do list，是手头要做的事，而且通常不会很多，只是马上要做的事，一般可能不会超过半天的工作量，至于为什么to do list膨胀，是不是因为积压，
而是因为完成的越来越多了，通常我将to do list放到javadoc中来（test case类开头）是因为那样很方便，毕竟在一个环境中开发比在窗口间切来切去好很多，至于为什么完成的仍然保留，我说了，我想是留下来作为一个目录使用的。如果说完成了最终都删除的话，那么所有的test case完成了什么的概况由什么来描述呢？需求？还是另外加的说明文档？我想用需求文档是不合适的，因为需求文档表面你想要什么，而不是你已经完成了什么。
不过关于to do list，其实无关紧要，关键是，对于test case这些类的javadoc怎么安排，是什么都没有吗？至少我看junit的测试类是这样的，基本上什么说明都没有，反而在类内部会有非javadoc的注释。
（回o6z）
关于“在开始之前我觉得就应该确定这些接口，而不是当别人需求调用的时候再去商量。”，我觉得很有疑问，一开始就确定好了的话，必须是需求很明确的，在提倡拥抱变化的敏捷过程中，怎么去做到呢？而“而我开发节奏是非常的小步跑，所以对于那些接口的规定不会是对于遥远以后事情的规定。”似乎又和前面那句不相同啊，既然设计不会考虑遥远的事，那怎么保证在不远的将来需求变更或者是其它原因带来的问题不会要求你重新商量下那些接口呢？
还有，TDD的状况下，怎么在没有代码的状况下完成设计？TDD本身，我个人理解是，写test first是确定需求，一旦test pass后开始重构，这个时候才是设计（当然是相对细节化的多些，不过大框架的也是一样的），也就是说，源代码就是设计，源代码完成设计才完成，那么怎么做到O6Z你所说的呢？
按照你的话（包括以前的讨论中），你应该是在没有动手写任何代码前有一个设计，而且至少是主要的开发人员都统一讨论通过的，甚至已经细化到方法级，
如果是这样的话，在完成了主要的设计后开始的TDD，是否有违它的初衷呢？或者其实它已经不是TDD了，因为开发过程其实在进行代码前已经完成至少一个迭代，即你的开发不是测试驱动的，在我看来，即使你动手写代码时是先写的test case，恐怕也不能完全的算test first，因为在写测试前你已经做了开发工作，虽然你的开发工作并不是反应到源代码上，但其本质是一样的，就是在没有测试的状况下的设计。
当然，我不是说，在开始写test case前什么概念也没有，不过，test first所提倡的test case的思考方式很不同，它首先让你考虑的不是what object do we need first? 而是 What test do we need first?，如果你已经完成一次迭代的设计，那么，你现在其实手里已经有了所有的对象了，你要做的只是去测试这些对象有没有按预期定义的那样工作，那么，显然是为了测试而测试了。（这个说的有点离题，不过上次看到你相关的话就有这样的疑问，不过任何非tdd开发方法都是这样的其实，所以我也认为合理，不过既然这回说了是TDD为前提了，就讨论讨论吧）
再说回主题，就是正常开发代码的javadoc，其实开始我这样理解了JAVADOC的作用，它至少是一种设计文档，因为大多数接口都有其局限性和适用性，这些都是要说明的，不过话说回来，也确实，应该说这样的代码多数还是因为要么它是框架代码，要么是因为它要作为一个公共包提供出来为大家服务，如果只是业务逻辑的代码，可能重用性要求没有那么高。
大概是因为很习惯查阅JDK DOC的原因，学习JAVA API多数依靠JAVADOC，所以会这样想，
而且，对于设计能和代码在一起，它和代码的同步相对应该是容易得多的，所以我才会倚重JAVADOC，一直以来也让我有点累，看来是要稍稍放松点了。
sorry，看来我随便带出来的话又模糊了。
通常我想是这样的，to do list，是手头要做的事，而且通常不会很多，只是马上要做的事，一般可能不会超过半天的工作量，至于为什么to do list膨胀，是不是因为积压，
而是因为完成的越来越多了，通常我将to do list放到javadoc中来（test case类开头）是因为那样很方便，毕竟在一个环境中开发比在窗口间切来切去好很多，至于为什么完成的仍然保留，我说了，我想是留下来作为一个目录使用的。如果说完成了最终都删除的话，那么所有的test case完成了什么的概况由什么来描述呢？需求？还是另外加的说明文档？我想用需求文档是不合适的，因为需求文档表面你想要什么，而不是你已经完成了什么。
不过关于to do list，其实无关紧要，关键是，对于test case这些类的javadoc怎么安排，是什么都没有吗？至少我看junit的测试类是这样的，基本上什么说明都没有，反而在类内部会有非javadoc的注释。
（回o6z）
关于“在开始之前我觉得就应该确定这些接口，而不是当别人需求调用的时候再去商量。”，我觉得很有疑问，一开始就确定好了的话，必须是需求很明确的，在提倡拥抱变化的敏捷过程中，怎么去做到呢？而“而我开发节奏是非常的小步跑，所以对于那些接口的规定不会是对于遥远以后事情的规定。”似乎又和前面那句不相同啊，既然设计不会考虑遥远的事，那怎么保证在不远的将来需求变更或者是其它原因带来的问题不会要求你重新商量下那些接口呢？
还有，TDD的状况下，怎么在没有代码的状况下完成设计？TDD本身，我个人理解是，写test first是确定需求，一旦test pass后开始重构，这个时候才是设计（当然是相对细节化的多些，不过大框架的也是一样的），也就是说，源代码就是设计，源代码完成设计才完成，那么怎么做到O6Z你所说的呢？
按照你的话（包括以前的讨论中），你应该是在没有动手写任何代码前有一个设计，而且至少是主要的开发人员都统一讨论通过的，甚至已经细化到方法级，
如果是这样的话，在完成了主要的设计后开始的TDD，是否有违它的初衷呢？或者其实它已经不是TDD了，因为开发过程其实在进行代码前已经完成至少一个迭代，即你的开发不是测试驱动的，在我看来，即使你动手写代码时是先写的test case，恐怕也不能完全的算test first，因为在写测试前你已经做了开发工作，虽然你的开发工作并不是反应到源代码上，但其本质是一样的，就是在没有测试的状况下的设计。
当然，我不是说，在开始写test case前什么概念也没有，不过，test first所提倡的test case的思考方式很不同，它首先让你考虑的不是what object do we need first? 而是 What test do we need first?，如果你已经完成一次迭代的设计，那么，你现在其实手里已经有了所有的对象了，你要做的只是去测试这些对象有没有按预期定义的那样工作，那么，显然是为了测试而测试了。（这个说的有点离题，不过上次看到你相关的话就有这样的疑问，不过任何非tdd开发方法都是这样的其实，所以我也认为合理，不过既然这回说了是TDD为前提了，就讨论讨论吧）
再说回主题，就是正常开发代码的javadoc，其实开始我这样理解了JAVADOC的作用，它至少是一种设计文档，因为大多数接口都有其局限性和适用性，这些都是要说明的，不过话说回来，也确实，应该说这样的代码多数还是因为要么它是框架代码，要么是因为它要作为一个公共包提供出来为大家服务，如果只是业务逻辑的代码，可能重用性要求没有那么高。
大概是因为很习惯查阅JDK DOC的原因，学习JAVA API多数依靠JAVADOC，所以会这样想，
而且，对于设计能和代码在一起，它和代码的同步相对应该是容易得多的，所以我才会倚重JAVADOC，一直以来也让我有点累，看来是要稍稍放松点了。
- 打赏
- 举报
ozzzzzz 2004-01-31
这个论题由我而起，是我说的我的开发方式使先写javadoc，然后再写具体的代码。看来我要解释一下了，不过其实 BirdGu(鲲鹏)上面已经说过了，我只不过具体的说一下。
我不是要求把所有的类和方法、参数都写到javadoc中去，那样没有必要，因为我对于代码优雅化的苛求，已经让它们可以满足说明自己的结构，而且再辅助以单元测试说明起功能，所以基本不会存在理解的问题，而且这个时候很少需要别人去理解你这些细节的问题。那么干吗要写那些javadoc呢？其实原因简单的很，因为你要给别人调用你的程序留下接口，并且需要对那些接口作出说明。在开始之前我觉得就应该确定这些接口，而不是当别人需求调用的时候再去商量。而我开发节奏是非常的小步跑，所以对于那些接口的规定不会是对于遥远以后事情的规定。在这个时候，你的代码还不存在，单元测试不存在，你的接口的测试自然也不会存在，所以需要你写这些javadoc。
而当你重构的时候，对于这些给别人留下的接口做重构绝对不是你一个人的事情。必须全面考虑协调。我对于在一个系统还为建成可以运行的程序前就开始大范围的重构是持反对观点的，这样的情况在我看来是系统框架胡乱的表现。而如果一个人需要写太多的javadoc，这肯定是在暗示，他开发的模块需要被很多的人调用，而这往往是起设计的内聚性差的表现。这个时候你应该从新划分工作责任，大家尽量少调用别人的代码。
如此你就可以把javadoc的数量保持一个低的水平，自然维护的成本就大大降低了。
我不是要求把所有的类和方法、参数都写到javadoc中去，那样没有必要，因为我对于代码优雅化的苛求，已经让它们可以满足说明自己的结构，而且再辅助以单元测试说明起功能，所以基本不会存在理解的问题，而且这个时候很少需要别人去理解你这些细节的问题。那么干吗要写那些javadoc呢？其实原因简单的很，因为你要给别人调用你的程序留下接口，并且需要对那些接口作出说明。在开始之前我觉得就应该确定这些接口，而不是当别人需求调用的时候再去商量。而我开发节奏是非常的小步跑，所以对于那些接口的规定不会是对于遥远以后事情的规定。在这个时候，你的代码还不存在，单元测试不存在，你的接口的测试自然也不会存在，所以需要你写这些javadoc。
而当你重构的时候，对于这些给别人留下的接口做重构绝对不是你一个人的事情。必须全面考虑协调。我对于在一个系统还为建成可以运行的程序前就开始大范围的重构是持反对观点的，这样的情况在我看来是系统框架胡乱的表现。而如果一个人需要写太多的javadoc，这肯定是在暗示，他开发的模块需要被很多的人调用，而这往往是起设计的内聚性差的表现。这个时候你应该从新划分工作责任，大家尽量少调用别人的代码。
如此你就可以把javadoc的数量保持一个低的水平，自然维护的成本就大大降低了。
- 打赏
- 举报
Schlemiel 2004-01-31
恩，同意BirdGu(鲲鹏)。to do list应该是你手头上积压着马上要干的活，要是to do list堆满了桌面，恐怕你该叫你们老大招个人什么的，帮你减减压。
- 打赏
- 举报
BirdGu 2004-01-31
又看了一遍顶楼的贴子，发现贴主说：“当需求膨胀的时候，to do list也会膨胀地离谱而难以维护，”。To do list还是不应该和需求混为一谈的。To do list应该是针对当前的任务而言的。
- 打赏
- 举报
Schlemiel 2004-01-31
刚才误操作了，呵呵。
想起个不恰当的比喻：to do list就好象需求文档，一条条是在说“我们要做什么”；test case就好象设计文档，一条条是在说“我们要怎么做这个”。Martin Fowler在《重构》里面说的做法也就是这样：想起有什么事要做，就拿张纸写下来，贴在电脑机箱上；要开始做这件事的时候，首先用test case把它描述下来，然后把纸条撕掉。等纸条撕干净了，单元测试也绿了，事情就做完了。
想起个不恰当的比喻：to do list就好象需求文档，一条条是在说“我们要做什么”；test case就好象设计文档，一条条是在说“我们要怎么做这个”。Martin Fowler在《重构》里面说的做法也就是这样：想起有什么事要做，就拿张纸写下来，贴在电脑机箱上；要开始做这件事的时候，首先用test case把它描述下来，然后把纸条撕掉。等纸条撕干净了，单元测试也绿了，事情就做完了。
- 打赏
- 举报
Schlemiel 2004-01-31
想起个不恰当的比喻：to do list就好象
- 打赏
- 举报
swinging 2004-01-31
楼上这点毫无疑问。
- 打赏
- 举报
BirdGu 2004-01-31
To do list和Test Case有个区别，To do list 一次可以写很多， Test Case一次最好只写一个。一次写下很多个Test Case,再一个、一个使它们通过，这并不是TDD所提倡的。
- 打赏
- 举报
BirdGu 2004-01-31
说明API如何使用的JavaDoc是给使用API的人写的。如果API还没有准备好给人用，那这时写了JavaDoc也没有用，如果以后还需要修改，那就更是浪费了宝贵的时间。
以前总把事后补文档批成大逆不道，但其实在一定条件下事后补文档比事前写更好。
以前总把事后补文档批成大逆不道，但其实在一定条件下事后补文档比事前写更好。
- 打赏
- 举报
加载更多回复
培训包9：华为LTE工程师HCNA认证 同步信号 24 同步信号.pptx ;目 录;1. 同步信号;2.同步信号的位置FDD帧中PSS与SSS的位置;2.同步信号的位置 TDD帧中PSS与SSS的位置;3.同步信号的作用主同步信号PSS的作用及编码;3.同步信号的作用辅同步信号SSS的作用和编码;
软件界旷世之架：测试驱动开发（TDD）之争 摘要：在软件行业中，神仙打架的名场面，那就不得不提的是2014年的那场——测试驱动开发（TDD）之争。 在历史上有很多精彩绝伦的神仙打架，比如数学界的牛顿和莱布尼茨关于微积分的旷世之争；比如量子物理中的...
TDD在Unity3D游戏项目开发中的实践 那么本文就来简单聊一聊TDD如何在U3D项目中使用以及如何使用U3D 5.3 .X之后版本已经集成的单元测试模块Editor Test Runner。 0x01 你好，TDD TDD，测试驱动开发改变了我们常见的工作流程，不要求先写逻辑...
如何说服你的同事使用TDD ？ TDD（Test-driven development），也就是我们常说的 “测试驱动开发”，是由 Kent Beck 在 1996 年提出的...为了让大家对 TDD 有一个具体而亲切的认识，我先给大家举一个在编程中使用 TDD 进行开发的实际例子。 Bob...
理解TDD 本文的目的是以最精炼的语言，正解什么是TDD，为什么要TDD，和TDD的难点。 什么是TDD？ 简单的说，TDD = 测试先行(TFD, Test First Development) + 重构(Refactoring) + 回归测试(Regression Test)。
TDD总结 大概的流程是先针对每个功能点抽象出接口代码，然后编写单元测试代码，接下来实现接口，运行单元测试代码，循环此过程，直到整个单元测试都通过。这一点和敏捷开发有类似之处。 2. 为什么要使用TDD 部分团队...
TDD测试驱动开发入门实践 最近和团队同学们分享了测试驱动开发实践，把分享的内容同步在博客上，主要分为三个方面，简单介绍软件测试的发展历程，为什么需要使用TDD，TDD的在编码中的实践。 一，软件测试的发展历程 调试为主： 怎么知道...
如何简单的理解TDD与DDT TDD：TEST-DRIVEN Development 测试驱动开发究竟是什么意思？如何理解测试驱动开发？ 举个红绿条简单的例子： 1.编写测试代码 2.编译运行测试代码，肯定会失败，因为实现代码还没有写 3.编写实现代码 4.运行...
Mocha中文文档 Mocha中文文档 javascriptnode.jsmocha 发布于 2017-09-26约 54 分钟 mocha中文文档 这个是对mocha文档的翻译，都是我一个字一个字敲出来的。水平有限，激情无限，欢迎大家批评指正。文档我也放在了我的github...
TDD 关于TDD测试驱动开发的文章已经有很多了，但是在游戏开发尤其是使用Unity3D开发游戏时，却听不到特别多关于TDD的声音。那么本文就来简单聊一聊TDD如何在U3D项目中使用以及如何使用U3D 5.3.X之后版本已经集成的单元...
单元测试+mocha使用+测试驱动开发（TDD） 和行为驱动开发（BDD） 学习单元测试单元测试简介：单元测试的内容mocha简介should.js测试驱动开发（TDD） 单元测试 简介： 代码部署之前，进行一定的单元测试是十分必要的，这样能够有效并且持续保证代码质量。而实践表明，高质量的...
什么是TDD 一、什么是TDD 简单的说，即在写任何功能代码之前，先写它的测试代码。具体步骤： ·根据需要编写一个测试用例 ·编写功能代码，以让刚才的测试用例通过 ·逐步补充测试用例 ·修改功能代码使新增的...
正解TDD
本文的目的是以最精炼的语言，正解什么是TDD，为什么要TDD，和TDD的难点。
什么是TDD？ 简单的说，TDD = 测试先行(TFD, Test First Development) + 重构(Refactoring) + 回归测试(Regression Test)。...
TDD的误解 （2006－08－12）前几天看到一篇《都在说TDD开发,那到底TDD是什么?》，感觉这个作者根本就没明白什么叫TDD。TDD还远达到如作者所说的“过份强调”的程度，甚至应该说还强调得不够。不可否认，“高质量的程序是...
敏捷质疑: TDD Q: 为什么通过单元测试发现的 Bug 很少 ? A: 单元测试不是用来发现 Bug 的, 而是用来预防 Bug 的....A: 关于这一点, 似乎有人不这么看, >. 不错, 代码质量并不必然关联到单元测试, 诸如净室软件开发之类的方法依然
信息系统项目管理师范文(采购管理).docx 信息系统项目管理师范文(采购管理).docx信息系统项目管理师范文(采购管理).docx信息系统项目管理师范文(采购管理).docx信息系统项目管理师范文(采购管理).docx信息系统项目管理师范文(采购管理).docx信息系统项目管理师范文(采购管理).docx信息系统项目管理师范文(采购管理).docx信息系统项目管理师范文(采购管理).docx
