需要强调的是：测试是一个持续的过程。也就是说测试贯穿与开发的整个过程中，单元测试尤其适合于迭代增量式（iterative and incremental）的开发过程。Martin Fowler（有点儿像引用孔夫子的话）甚至认为：“在你不知道如何测试代码之前，就不应该编写程序。而一旦你完成了程序，测试代码也应该完成。除非测试成功，你不能认为你编写出了可以工作的程序。”我并不指望所有的开发人员都能有如此高的觉悟，这种层次也不是一蹴而就的。但我们一旦了解测试的目的和好处，自然会坚持在开发过程中引入测试。因为我们是测试新手，我们也不理会那些复杂的测试原理，先说一说最简单的:测试就是比较预期的结果是否与实际执行的结果一致。如果一致则通过，否则失败。看下面的例子：
//将要被测试的类
public class Car
{
public int getWheels()
{
return 4;
}
}
//执行测试的类
public class testCar
{
public static void main(String[] args)
{
testCar myTest = new testCar();
myTest.testGetWheels();
}
public void testGetWheels ()
{
int expectedWheels = 5;
Car myCar =new Car();
if (expectedWheels==myCar.getWheels())
System.out.println("test [Car]: getWheels works perfected!");
我们目前所能做的就是尽量降低所付出的代价：我们编写的测试代码要能被维护人员容易的读取，我们编写测试代码要有一定的规范。最好IDE工具可以支持这些规范。好了，你所需要的就是JUnit。一个Open Source的项目。用其主页上的话来说就是：“ JUnit是由 Erich Gamma 和 Kent Beck 编写的一个回归测试框架（regression testing framework）。用于Java开发人员编写单元测试之用。”所谓框架就是Erich Gamma 和 Kent Beck 定下了一些条条框框，你编写的测试代码必须遵循这个条条框框：继承某个类，实现某个接口。其实也就是我们前面所说的规范。好在JUnit目前得到了大多数软件工程师的认可。遵循JUnit我们会得到很多的支持。回归测试就是你不断地对所编写的代码进行测试：编写一些，测试一些，调试一些，然后循环这一过程，你会不断地重复先前的测试，哪怕你正编写其他的类，由于软件熵的存在，你可能在编写第五个类的时候发现，第五个类的某个操作会导致第二个类的测试失败。通过回归测试我们抓住了这条大Bug。
二、JUnit简介及为什么要使用JUint
JUnit就是对程序代码进行单元测试的一种Java框架。通过每次修改程序之后测试代码，程序员就可以保证代码的的少量变动不会破坏整个系统。要不是有Junit这样的自动化测试工具，代码的的反复测试简直会把人累死而且还可能不准确。现在好了，测试过程可以频繁进行而且还是自动的，所以你可以令程序错误降低到最少。它写的是单元测试（Unit Test）：软件工程里的白盒测试，就是测试某个类的某个方法的功能。XP 中推崇的 test first design 就是基于以上的技术。
从技术上强制你先考虑一个类的功能，也就是这个类提供给外部的接口，而不至于太早陷入它的细节。这是面向对象提倡的一种设计原则。好的测试其实就是一个好的文档，这个类使用者往往可以通过查看这个类的测试代码了解它的功能。特别的，如果你拿到别人的一个程序，对他写测试是最好的了解这个程序的功能的方法。 xp的原则是 make it simple，不是很推荐另外写文档，因为项目在开发过程中往往处于变动中，如果在早期写文档，以后代码变动后还得同步文档，多了一个工作，而且由于项目时间紧往往文档写的不全或与代码不一致，与其这样，不如不写。而如果在项目结束后再写文档，开发人员往往已经忘记当时写代码时的种种考虑，况且有下一个项目的压力，管理人员也不愿意再为旧的项目写文档，导致以后维护的问题。没有人能保证需求不变动，以往项目往往对需求的变动大为头疼，害怕这个改动会带来其他地方的错误。为此，除了设计好的结构以分割项目外（松耦合），但如果有了测试，并已经建立了一个好的测试框架，对于需求的变动，修改完代码后，只要重新运行测试代码，如果测试通过，也就保证了修改的成功，如果测试中出现错误，也会马上发现错在哪里，修改相应的部分，再运行测试，直至测试完全通过。
软件公司里往往存在开发部门和测试部门之间的矛盾：由于开发和测试分为两个部门，多了一层沟通的成本和时间，沟通往往会产生错误的发生。而且极易形成一个怪圈：开发人员为了赶任务，写了烂烂的代码，就把它扔给测试人员，然后写其他的任务，测试当然是失败的，又把代码拿回去重写，而且在国内往往一个软件公司技术最差的部门就是测试部门（好的人都跑去写代码了），测试就成了一个很头疼的问题。这种怪圈的根源是责任不清，根据 xp 中的规定：写这个代码的人必须为自己的代码写测试，而且只有测试通过，才算完成这个任务（这里的测试包括所有的测试，如果测试时发现由于你的程序导致别的模块的测试失败，你有责任通知相关人员修改直至集成测试通过），这样就可以避免这类问题的发生。