Junit是对程序代码进行单元测试的一种Java框架。通过每次修改程序之后测试代码，程序员可以保证代码的少量变动不会破坏整个系统。要不是有Junit这样的自动化测试工具，代码的反复测试简直会把人累死而且还可能不准确。现在好了，测试过程可以频繁的进行而且还是自动的，所以你可以令程序错误减低到少。它写的是单元测试（Unit Test）：软件工程里的白盒测试，是测试某个类的某个方法的功能，XP中推崇的test first design是基于以上技术的。

    假如你要写一段代码：

    1：先用Junit写测试，然后再写代码。

    2：写完代码，运行测试，测试失败。

    3：修改代码，运行测试，直到测试成功。

    假如以后对程序进行修改，优化（refactoring），只要再运行测试代码，假如所有的测试都成功，则代码修改完成。

    Java下的team开发，一般采用cvs（版本控制），ant（项目治理），Junit（单元测试）的模式。

    先写测试，再写代码的好处：

    从技术上强制你先考虑一个类的功能，也是这个类提供给外部的借口，而不至于太早陷入它的细节。这是面向对象提倡的一种设计原则。好的测试其实是一个好的文档，这个类使用者往往可以通过查看这个类的测试代码了解它的功能。一般的，假如你拿到别人的程序，对他写的测试解读是了解程序工程的好的方法。xp原则是make it simple，不是很推荐另外的文档，因为项目在开发过程中往往处于变动中，假如在早期写文档，以后代码变动还得的同步文档，多了一个工作，而且由于项目时间紧，往往文档写的不全或者与代码不一致，与其这样，不如不写。而假如在项目结束后写文档，开发人员往往已经忘记当时写代码时的种种考虑，况且有下一个项目的压力，治理人员也不愿意再为旧的项目写文档，导致以后维护的问题。没有人能保证需求不变动，以往项目往往对需求的变动大为头疼，害怕这个改变会带来其他地方的错误。为此，除了设计好的结构可以分割项目外（松耦合），但假如有了测试，并已经建立了一个好的测试框架，对于需求的变动，修改完代码后，只要从新运行测试代码，假如通过了测试，也保证了修改的成功，假如测试中出现错误，也会马上发现错在哪里，修改相应的部分，再运行测试，直到测试完全通过。

    根据xp的规定：写代码的人必须为自己的代码写测试，而且只有测试通过，才算完成这个任务（这里的测试包括所有的测试，假如测试时发现由于你的程序导致别的模块的测试失败，你有责任通知相关人员修改直至集成测试通过），这样可以避免这类问题的发生。