在信息技术中，单元测试是检验代码原子构成的实践，越小的原子构成，越好的进行检测。OOP中的一个单元，通常指一个类至少需要一个测试检查每个类的公共方法。然而，在实践中什么是一个测试？一个测试是一个单独的函数，执行一个单独的动作并检查执行的动作提供期待的结果。如果结果正确，测试通过；否则测试失败。通过单元测试，开发者的工作会更轻松，因为当一个 bug 并非自愿的在不断改动中被添加到代码，很可能一个已经编写的测试会失败可以指出一定精确程度的出错位置。当代码需要广泛的测试时（一个代码覆盖率的概念），可以进行这项工作。当遇到一个错误，并且没有测试失败，最好是编写一个新的测试准确的重现相同的错误。通过这个方式，会很容易检查，以使在随后的改动中这个故障不会再次偶然出现。 许多开发者认为单元测试浪费时间。可能因为他们没有考虑一个良好的测试基础会对他们的项目有多么积极的影响。有一个好的代码覆盖率意味着代码的改动可以更有信心，因为如果一些危险的东西被触及，测试会失败帮助你解决这个问题。另一个测试的好处是他们为想要使用这个经过测试的库的开发者提供了真实的例子；测试中的代码非常易读，因为它是为了自身的性质，并提供了一种在线的文档。一个积极的作用是，一个曾经编写测试的开发者更关注编写具有较少的依赖性的代码，而且更独立于上下文环境：因为测试依赖过多的类的确很痛苦。 单元测试的概念并没有明确的结合到一个技术实现，而且潜在地一个单元测试也可以是一组手写在一张纸条上的说明；使测试真正有效的是，当他们被集中在一个自动化的背景中。 测试聚集于一个处理单元，一次性执行它们所有的测试，报告测试运行的数量，并报告测试失败的适量和它们的名字。自动处理被重复多次，在开发中可以帮助定位 bug ， 这也是为什么测试经常用来优化性能。开发者往往在它们执行的太慢或者使他们工作太辛苦时放弃测试。 单独的测试也在执行的上下文中，每个测试必须独立于其它的，必须不依赖于某个特定的配置。如果测试互相连接，一个错误可能破坏整个测试链，使得 bug 更加难以发现。环境不应该影响测试，因为这是危险的，测试可能被移走，应用到另外一个机器上，所以应该有最小的配置依赖。 有些地方不是那么容易适合单元测试，通常 UI 和数据库。因为第一种情况，用户交互界面是必须的，往往会丢掉自动化处理的好处。数据库难以测试基于各种事实：他们必须被配置，表结构必须存在，测试数据必须以某种方式持续的生成和删除，并且当同样的测试重复时有相同的状态。开发者社区提供许多策略处理这些问题，在更深的层次介绍单元测试技术，这超出了本书的范围。