单元测试 单元测试工具
单元测试是在软件开发过程中要进行的最低级别的测试活动，单元测试是对软件中的基本组成单位进行的测试，如一个模块、一个过程等等。在单元测试活动中，软件的独立单元将在与程序的其他部分相隔离的情况下进行测试。它是软件动态测试的最基本的部分，也是最重要的部分之一，其目的是检验软件基本组成单位的正确性。因为单元测试需要知道内部程序设计和编码的细节知识，一般应由程序员而非测试员来完成，往往需要开发测试驱动模块和桩模块来辅助完成单元测试。因此应用系统有一个设计很好的体系结构就显得尤为重要。
一个软件单元的正确性是相对于该单元的规约而言的。因此，单元测试以被测试单位的规约为基准。单元测试的主要方法有控制流测试、数据流测试、排错测试、分域测试等等。
在一种传统的结构化编程语言中，比如Java、C++这样的面向对象的语言中，要进行测试的基本单元是类，尤其是一些公用类;而C，则要进行测试的单元一般是函数或子过程。对Ada语言来说， 开发人员可以选择是在独立的过程和函数，还是在Ada包的级别上进行单元测试。
单元测试不仅仅是作为无错编码的一种辅助手段在开发过程中使用。单元测试也应该是可重复的， 无论是在软件修改， 或是移植到新的运行环境的过程中。因此，所有的测试都必须在整个软件系统的生命周期中进行维护。
经常与单元测试联系起来的另外一些开发活动包括代码走读(Code Walkthrough/Review)、代码审查(Code Inspection)、 静态分析(Static Analysis)和动态分析(Dynamic Analysis)。 静态分析就是对软件的源代码进行研读，查找错误或收集一些度量数据，并不需要对代码进行编译和执行。而动态分析就是通过观察软件运行时的动作，来提供执行跟踪，时间分析，及测试覆盖度方面的信息。
在明确了什么是单元测试以后，我们列出了一些反对单元测试的普遍的论点，通过这些看起来。
然后用充分的理由来证明这些论点是不足取的。
3.1 浪费时间
一旦编码完成， 开发人员总是会迫切希望进行软件的集成工作， 这样他们就能够看到实际的系统开始运行了。能看到实际的工作成果总是令人振奋的，而象单元测试这样的活动也许会被看作是通往这个阶段点的道路上的障碍， 推迟了对整个系统进行联调这种真正有意思的工作启动的时间。
在这种开发步骤中，真实意义上的进步被外表上的进步取代了。系统能够正常工作的可能性是很小的，更多的情况是充满了各式各样的缺陷。 在实践中，这样一种开发步骤常常会导致这样的结果：软件甚至无法运行。更进一步的结果是大量的时间将被花费在跟踪那些包含在独立单元里的简单的Bug上面，在个别情况下，这些Bug也许是琐碎和微不足道的，但是总的来说，他们会导致在软件集成为一个系统时增加额外的工期，
而且当这个系统投入使用时也无法确保它能够可靠运行。
在实践工作中， 进行了完整计划的单元测试和编写实际的代码所花费的精力大致上是相同的。 一旦完成了这些单元测试工作， 很多Bug将被纠正，在确信他们手头拥有稳定可靠的部件的情况下， 开发人员能够进行更高效的系统集成工作。 这才是真实意义上的进步，所以说完整计划下的单元测试是对时间的更高效的利用。 而调试人员的不受控和散漫的工作方式只会花费更多的时间而取得很少的好处。
使用Junit Framework和Jtest这样的支持工具可以使单元测试更加简单和有效。 但这不是必须的，单元测试即使是在没有工具支持的情况下也是一项非常有意义的活动。
3.2 它仅仅是证明这些代码做了什么
文章来源于领测软件测试网 https://www.ltesting.net/
