简而言之，如果程序设计师要写一段代码：
先用 junit 写测试，然后再写代码;
写完代码，运行测试，如果测试失败，
修改代码，运行测试，直到测试成功。
如果以后对程序进行修改，优化 ( refactoring )，只要再运行测试代码。如果所有的测试都成功，则代码修改完成。
3. 单元测试与Java Team开发的结合
Java下的team开发，一般采用cvs(版本控制) + ant(项目管理) + junit(单元测试、集成测试)的模式：
每天早上上班，每个开发人员从 cvs server 获取一个整个项目的工作拷贝。
拿到自己的任务，先用 junit 写今天的任务的测试代码。
然后写今天任务的代码，运行测试(单元测试)，直到测试通过。
任务完成在下班前一两个小时，各个开发人员把任务提交到cvs server。
然后由主管对整个项目运行自动测试(集成测试)，哪个测试出错，就找相关人员修改，直到所有测试通过。下班......
4.测试控制工具中要有甚么?
无论谁来撰写单元测试或何时撰写单元测试，我们的焦点应该放在检验程序代码;主要是在于产生错误的风险。如果设计文件包含被测试对象的使用情节;便可成为好的测试来源。不管如何，这些情节写得不是很明确;因为这些情节实际上是以设计观点所写的--因此适当的测试应该有对等的情节，换句话说，也就是测试设计应该尽可能的包含用户实际使用程序时可能产生的动作或者过程。
另一个测试案例好的来源是在整合后从产品程序代码当中找到的问题，维修问题的处理方式往往值得封装成为测试案例。
5. 为什么要使用Junit等工具呢?
前面的论述说明为什么我们需要测试控制工具，但为什么我们使用Junit这些工具呢?
首先，它们是完全Free的!
第二点，使用方便。
在你提升程序代码的品质时JUnit测试仍允许你更快速的撰写程序!
那听起来似乎不是很直觉，但那是事实。当你使用JUnit撰写测试，你将花更少的时间除虫，同时对你程序代码的改变更俱有信心。这个信心让你更积极重整程序代码并增加新的功能。没有测试，对于重整及增加新功能你会变得没有信心;因为你不知道有甚么东西会破坏产出的结果。采用一个综合的测试系列，你可以在改变程序代码之后快速的执行多个测试并对于你的变动并未破坏任何东西感到有信心。在执行测试时如果发现臭虫，原始码仍然清楚的在你脑中，因此很容易找到臭虫。在JUnit中撰写的测试帮助你以一种极大(extreme)的步伐撰写程序及快速的找出缺点。
JUnit非常简单
撰写测试应该很简单--这是重点!如果撰写测试太复杂或太耗时间，便无法要求程序设计师撰写测试。使用JUnit你可以快速的撰写测试并检测你的程序代码并逐步随着程序代码的成长增加测试。只要你写了一些测试，你想要快速并频繁的执行测试而不至于中断建立设计及开发程序。使用JUnit执行测试就像编译你的程序代码那么容易。事实上，你应该执行编译时也执行测试。编译是检测程序代码的语法而测试是检查程序代码的完整性(integrity)。
文章来源于领测软件测试网 https://www.ltesting.net/
