1.每日构建（Daily Build）
在项目中使用每日构建（Daily Build）是为了实现“持续集成”。传统构建只发生在项目发布前夕很短的一段时间，压力和风险不小。每日构建一定程度上缓解了这种压力，削平了曲线。好东西！但每日构建也需项目组的投入，学习和使用Ant（或Nant）就是一个不错的办法。
2.单元测试（Unit Test）
在项目中使用单元测试（Unit Test）和每日构建在思想上有相似之处，在实践中又交相呼应。单元测试可以确保每个软件项目最小逻辑部件的正确性。在耦合始终存在的情况下，单元测试的作用其实也被放大了，对某个逻辑部件的测试自然也包括了对所引用其他部件的测试（虽然这并不是单元测试的初衷）。单元测试不是最重要的，但的确是非常重要的和必须的。单元测试也需要项目组的投入，编写单元测试用例是起码的，学习和使用JUnit（或Nunit）能帮上不小的忙。
3.结合起来（Do Them All）
单元测试的最佳实施者是每个开发人员自己，也可以采用同行测试（Buddy Test）。他们阅读设计文档，编写单元测试用例、编写逻辑部件，然后把逻辑部件放到测试用例中测试，测试通过就继续往前走。单元测试的发起者是项目组中单个的开发者时，会使得单元测试此起彼伏，但问题是有些单元测试有很多都是无效的。原因很简单，因为不同开发者编写的逻辑部件之间的耦合只要存在，这样的单元测试就是无效的。参考《软件配置管理模式》一书中关于“活动开发线”模式的讲述：当在项目的一条码线（Code Line）上，测试与开发在时间上同存时，测试都是无效的，单元测试也不例外。
也许在开发者自行单元测试的同时，我们还应该定时的让所有的开发者都停下来，提交他们的代码，然后一起来进行单元测试。其实这不难，每天下班的时候他们都会自动的停下来，如果项目的配置管理还算可以的话，他们也都会在下班前提交代码，然后让我们来运行单元测试吧。
我们用Ant来进行每日构建。同样，我们也可以让Ant+JUnit帮助我们进行每日单元测试（Daily Test？）。每次听微软的讲师讲MSF，都要讲他们的开发是深夜12:00开始的，也就是“自动构建+自动测试”，第二天早上，开发组的人拿到自动生成的报告，该code的就code，该debug的就debug。（其实，这也就是一种测试驱动开发：Test-Driven Development，又一个很多人争议的软件方法。）这不难，是看公司要不要这么做。
4.实践（Practice）
关于使用Ant实现每日构建的请看陋文：“一个轻巧的每日构建解决方案”。
在此基础上，在Ant的“build.xml”中加入单元测试任务即可，同时也可以生成单元测试报告。甚至可以将单元测试结果报告通过email发送给开发组成员。
先请出国内外的几篇好文：
到今天（2004-08-20）为止，在Google上面以“ant+junit”可以搜出127000条记录，大家都做得很好。但上面3篇的确已经足够帮助还未实作的人快速的实现“每日构建+单元测试”了。
关于实践他们都说得很清楚，我也是在看了这些文档后完成实践的。我在自己的Blog上加点自己的东西吧，也就是在实现“每日构建+单元测试”时的小贴士。
1)环境配置之<mail>
“让编译和测试过程自动化”一文的作者Erik Hatcher也是Ant的开发者之一。但此文有些早了，文中所提到的Ant的<mimemail>
CLASSPATH：
C:\javamail-1.3.2ea\mail.jar;
C:\javamail-1.3.2ea\lib\mailapi.jar;
C:\javamail-1.3.2ea\lib\pop3.jar;
C:\javamail-1.3.2ea\lib\smtp.jar;
C:\jaf-1.0.2\activation.jar;
这样才能保证Ant以email发送构建和测试报告时的正确。
2)环境配置之<junit><junitreport>
如果项目组在白天用的是JBuilder，其中集成了JUnit和Ant。（建议下载单独的Ant和JUnit）但当晚上Ant调用JUnit执行测试任务时，必须保证
C:\ant\lib
这样才能保证，Ant+JUnit会为你生成漂亮的html格式的测试报告，并发送到你指定的email中。
5.总结（Summary）
讨论了每日构建和单元测试的作用和结合起来使用的理由。配合软件开发配置管理模式提出了供参考的结合方法，并通过实践验证该方案的可行性和简单性。最后和java不太熟练的朋友分享了少量经验。
