本文探讨了程序员在单元测试中遇到的时间和工具效率问题，并提出使用模拟对象作为解决方案。通过模拟对象，可以在不依赖实际数据库的情况下进行单元测试，简化了测试过程，提高了测试效率。文中以Java为例，展示了如何在Eclipse环境中使用JUnit和模拟对象进行测试，强调了接口编程在创建模拟对象中的作用。
如今，程序员比以往更多地认识到他们有责任创建编写较好的单元测试。无论一个开发人员是在进行测试驱动的开发（TDD）还是在编写代码后创造单元测试，有一点是十分明显的，那就是单元测试有助于产出高质量、无缺陷的代码。
即便开发人员知道测试的益处，我们也会发现程序员们不愿意测试他们的代码。他们会列出各种理由，如时间不够、没有有效的工具以及在编写带有许多有依赖关系的对象的测试方面有问题。
本期的文章中，我想将重点放在单元测试上，并看看如何解决这些问题。特别地，我想提供一些技巧来说明编写带有模拟对象的单元测试是多么容易。
对于单元测试的常见异议
在深入探讨模拟对象之前，让我们先来看一下以下两点异议。
花费时间太长
我们很早就认识到这样一个原则“做事情需要花费时间”，特别当这些事情值得去做。很少的开发人员会怀疑整体测试的价值，因此我们需要考虑如何定义“太长”这个词的含义。
开发人员们缺乏耐心，他们想要的是结果。他们喜欢写代码、运行代码然后看结果。从这一点来说，单元测试对他们有帮助。单元测试满足开发人员们的及时需求，但是许多程序开发人员认为编写测试占据了他们编写应用程序代码的时间，而他们的工作是按照后者计算报酬的。当然如果您仅仅按照程序开发人员在一个特定时间创建的应用程序代码的行数（或者一些其他方法）来计算的话，这一点是正确的。但是我们必须考虑每行代码所承载的全部时间。如果每当代码编译完成并运行通过我们就停止计算的话，我们可能会忽略掉创建软件最重要的部分—消除缺陷。在软件开发周期中越晚发现缺陷，修复缺陷所花费的代价会随之成倍增长。在开发过程中许多预先的质量检验会多占用一点点时间，但是会在以后节约大量时间。这一点已经被许多研究所证实。
仍有许多程序设计人员认为找出他们代码中的错误是其他一些人的工作。我发现近十年来这种情况已经有了显著的改进，但是仍有大量的程序人员并没有为他们的工作负全责，他们也不使用有助于改进他们代码的工具和技术。在早期的软件工程课程中我向我的学生们介绍过单元测试。我告诉他们如何使用现代工具编写测试。我布置了关于编写单元测试的作业。然而，当给他们机会在工作中采用有效的单元测试时，只有25%的学生这样做。原因是什么呢？因为他们还没
即便开发人员知道测试的益处，我们也会发现程序员们不愿意测试他们的代码。他们会列出各种理由，如时间不够、没有有效的工具以及在编写带有许多有依赖关系的对象的测试方面有问题。
本期的文章中，我想将重点放在单元测试上，并看看如何解决这些问题。特别地，我想提供一些技巧来说明编写带有模拟对象的单元测试是多么容易。
对于单元测试的常见异议
在深入探讨模拟对象之前，让我们先来看一下以下两点异议。
花费时间太长
我们很早就认识到这样一个原则“做事情需要花费时间”，特别当这些事情值得去做。很少的开发人员会怀疑整体测试的价值，因此我们需要考虑如何定义“太长”这个词的含义。
开发人员们缺乏耐心，他们想要的是结果。他们喜欢写代码、运行代码然后看结果。从这一点来说，单元测试对他们有帮助。单元测试满足开发人员们的及时需求，但是许多程序开发人员认为编写测试占据了他们编写应用程序代码的时间，而他们的工作是按照后者计算报酬的。当然如果您仅仅按照程序开发人员在一个特定时间创建的应用程序代码的行数（或者一些其他方法）来计算的话，这一点是正确的。但是我们必须考虑每行代码所承载的全部时间。如果每当代码编译完成并运行通过我们就停止计算的话，我们可能会忽略掉创建软件最重要的部分—消除缺陷。在软件开发周期中越晚发现缺陷，修复缺陷所花费的代价会随之成倍增长。在开发过程中许多预先的质量检验会多占用一点点时间，但是会在以后节约大量时间。这一点已经被许多研究所证实。
仍有许多程序设计人员认为找出他们代码中的错误是其他一些人的工作。我发现近十年来这种情况已经有了显著的改进，但是仍有大量的程序人员并没有为他们的工作负全责，他们也不使用有助于改进他们代码的工具和技术。在早期的软件工程课程中我向我的学生们介绍过单元测试。我告诉他们如何使用现代工具编写测试。我布置了关于编写单元测试的作业。然而，当给他们机会在工作中采用有效的单元测试时，只有25%的学生这样做。原因是什么呢？因为他们还没
最低0.47元/天 解锁文章
扫一扫
873
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
