有关TDD(Test-Driven Development)和持续集成（Continuous Integration）

   在最近的工作中接触到了TDD，其实严格的说也不能算纯粹的TDD，不过test已经覆盖了大部分的代码功能点，持续集成方面采用的软件是anthill，当然还有CruiseControl可以选择。


   有关TDD和持续集成都足够独立成文，也有很多相关的介绍文章，这里只是简单描述下我们的做法：
     1。保证大部分功能点都有相关的test（因为某些原因，我们没有做到TDD要求的测试先行，有待以后改进）
     2。在ant脚本中加入JUnit test部分，目的是达到自动执行批量test并且能够test fail->build fail。
     3。在版本控制器（svn）上加上anthill的支持

    这样协作开发的步骤就是：从svn update 代码->首先进行cleanbuild确保修改前的代码是无错的->进行代码及相应test的修改（按照TDD这里的顺序应该是反过来）- >再次cleanbuild确保修改后的代码是无错的->svn commit->通过anthill web界面进行build查看结果
全部正确就算完成了一次修改，可以看出test和持续集成的作用，既保证了代码实时的正确性，又保证了trouble shooting的准确快速。


   无怪spring和pico的作者都提到TDD从某种程度上讲是致瘾的，习惯了它的开发者很难再回到原来的开发模式。想来一定是会感到缺乏安全感吧：）回想以前总是担忧自己项目中bug横行却无计可施的日子，恐怕真的离不开test了。



必要的软件：
  Eclipse－最重要的了，提供了对Junit和Refactoring的良好支持
  JUnit－使test细致到function一级，以清晰的红绿灯显示测试的结果
  Ant－支持自动化的test过程
  EasyMock－如果你使用MockObject协助test
  anthill（CruiseControl）－持续集成软件



推荐的参考读物：
http://news.csdn.net/news/newstopic/21/21164.shtml Martin Fowler：持续集成
Test-Driven Development A Practical Guide 测试驱动开发实用指南（中国电力出版社）jolt大奖得主哦

谢谢楼主的分享。

进行代码及相应test的修改（按照TDD这里的顺序应该是反过来）

为什么不按照tdd的顺序呢？
是因为先改代码更方便？

还是编程习惯问题吧，软件工程中测试总是排在开发后面不是么，呵呵

我想知道的是,tdd下如何Refactor.比如我写好测试,然后写好功能.然后重构,我把一个方法重构成几个小方法了,然后写测试?还是要重构方法之前,先重构测试?有经验的介绍一下吧...

我想知道的是,tdd下如何Refactor.比如我写好测试,然后写好功能.然后重构,我把一个方法重构成几个小方法了,然后写测试?还是要重构方法之前,先重构测试?有经验的介绍一下吧...


怎么提交了两次,建议加一个删除功能.

实际项目中，完全做到TDD，也不容易啊。
主要是里面不明确的东西，有点多。

按照tdd的思想，重构当然是先从测试开始。首先break掉test，再通过修改代码修复它。这样才是small step的测试先行啊。

重构并不改变类的外部行为,所以一般情况下不需要写测试.只要保证原来的测试仍然通过就是可以了.

我的理解也是这样的. 如果改变方法的功能的话，估计那叫重做。哈哈

我目前写测试是：junit写的测试和方法对应。比如有do1 do2 那么对应就有testDo1 testDo2。如果按照tdd的话，就先写testDo1在写do1这样的顺序。如果我重构的话，只改变do1的代码，而没有改变功能，那么就不需要修改testDo1，那么按照你的说法肯定可行。那如果我抽出了几个私有方法，就是助手方法，怎么测？这些方法需要测吗？如果要测的话，那么方法肯定是先出来的，在写测试。这又与tdd有些矛盾了。 还是那里没有理解，还是太执着了tdd了？呵呵

希望有人可以详细介绍一下自己的实践经验

一般情况下是地
当使用了mock测试的时候就是非一般情况吧，如果mock测试描述了被测试组件的内部行为，有时需要先对它进行修改