类开发
对我来说，类开发是从编写 main() 方法开始的。我在编写 main() 的时候就定义类和类的用法，然后实现接口。它的一些明显的缺陷也开始显现出来。一个缺陷是我传递给 main() 来执行测试的参数个数。其次， main() 本身在进行调用子方法、设置代码等操作时变得很混乱。有时 main() 会比类实现的其余部分还要大。
更简单的过程
我原来的做法有一些很明显的缺陷。因此，让我们看看有什么别的方法可以使问题简化。我仍然通过接口设计代码并给出应用示例，正如原来的 main() 一样。不同的是我将代码放到了另一个单独的类中，而这个类恰好是我的“单元测试”。这种技术有以下几点好处：
设计类的一种机制
因为是通过接口进行开发，所以不太可能利用类的内部功能。但因为我是目标类的开发者，我有到其内部工作的“窗口”，所以测试并不是个真正的黑箱。仅凭这一点就足够推断出需要开发者本人在编写目标类的同时负责测试的开发，而不是由其他任何人代劳。
类用法的示例
通过将示例从实现中分离出来，开发者可以更快地提高速度，而且再不用在源代码上纠缠不清。这种分离还有助于防止开发者利用类的内部功能，因为这些功能将来可能已经不存在了。
没有类混乱的 main()
我不再受到 main() 的限制了。以前我得将多个参数传递给 main() 来测试不同的配置。现在我可以创建许多单独的测试类，每一个都维护各自的设置代码。
接下来我们将这个单独的单元测试对象放入构建过程中。这样，我们就可以提供自动确认过程的方法。
确保所做的任何更改都不会对其他人产生不利影响。
我们在进行源码控制之前就可以测试代码，而无需等待汇编测试或在夜晚进行的构建测试。这有助于尽早捕捉到“臭虫”，从而降低产生高质量代码的成本。
通过提供增量测试过程，我们提供了更好的实现过程。如同 IDE 帮助我们在输入时捕捉到语法或编译“臭虫”一样，增量单元测试也帮助我们在构建时捕捉到代码更改“臭虫”。
使用 JUnit 自动化单元测试
要使测试自动化，您需要一个测试框架。您可以自己开发或购买，也可以使用某些开放源代码工具，例如 JUnit。我选择 JUnit 出于以下几个原因：
不需要编写自己的框架。
文章来源于领测软件测试网 https://www.ltesting.net/
