JUnit的框架设计及其使用的设计模式.docxVIP

JUnit的框架设计及其使用的设计模式 1、介绍 　　在较早的 HYPERLINK javascript:; \t _self 文章（ HYPERLINK javascript:; \t _self Test Infected： Programmers Love Writing Tests）中，我们描述了如何用一个简单的框架编写可重复的 HYPERLINK javascript:; \t _self 测试；本文则说明这个框架是如何构造的。 　　仔细地学习 HYPERLINK javascript:; \t _self JUnit框架，从中可以看出我们是如何设计这个框架的。我们看到不同层次的JUnit教程，但在本文中，我们希望更清楚地说明问题。弄清JUnit的设计思路是非常有价值的。 　　我们先讨论一下Junit的目标，这些目标会在JUnit的每个细小之处得到体现。围绕着JUnit的目标，我们给出Junit框架的设计和实现。我们会用模式和程序实现例子来描述这个设计。我们还会看到，在开发这个框架时，当然还有 HYPERLINK javascript:; \t _self 其它的可选途径。 　　2、目标 　　什么是JUnit的目标？ 　　首先，我们回到开发的前提假设。我们假设如果一个程序不能自动测试，那么它就不会 HYPERLINK javascript:; \t _self 工作。但有更多的假设认为，如果开发人员保证程序能工作，那么它就会永远正常工作，与与这个假设相比，我们的假设实在是太保守了。 　　从这个观点出发，开发人员编写了代码，并进行了调试，还不能说他的工作完成了，他必须编写测试脚本，证明程序工作正常。然而，每个人都很忙，没有时间去进行测试工作。他们会说，我编写程序代码的时间都很紧，那有时间去写测试代码呢？ 　　因此，首要的目标就是，构建一个测试框架，在这个框架里，开发人员能编写测试代码。框架要使用熟悉的工具，无需花很多精力就可以掌握。它还要消除不必要的代码，除了必须的测试代码外，消除重复劳动。 　　如果仅仅这些是测试要作的，那么你在调试器中写一个表达式就可以实现。但是，测试不仅仅这些。虽然你的程序工作很好，但这不够，因为你不能保证集成后的即使一分钟内你的程序是否还会正常，你更不能保证5年内它还是否正常，那时你已经离开很久了。 　　因此，测试的第二个目标就是创建测试，并能保留这些测试，将来它们也是有价值的，其它的人可以执行这些测试，并验证测试结果。有可能的话，还要把不同人的测试收集在一起，一起执行，且不用担心它们之间互相干扰。 　　最后，还要能用已有的测试创建新的测试。每次创建新的测试设置或测试钳（test fixture）是很花费代价的，框架能复用测试设置，执行不同的测试。 　　3、JUnit设计 　 　最早，JUnit的设计思路源于用模式生成架构（Patterns Generate Architectures）一文。它的思想就是，从0开始设计一个系统，一个一个地应用模式，直到最后构造出这个系统的架构，这样就完成一个系统的设 计。我们马上提出要解决的架构问题，用模式来解决这个问题，并说明如何在JUnit中应用这些模式的。 　　3.1、从测试用例TestCase开始 　　首先我们创建一个对象来表示基础概念：测试用例（TestCase）。测试用例常常就存在于开发人员的 　　头脑中，他们用不同的方式实现测试用例： 　　打印语句 　　调试表达式 　　测试脚本 　 　如何我们想很容易地操纵测试，那么就必须把测试作为对象。开发人员脑海中的测试是模糊的，测试作为对象，就使得测试更具体了，测试就可以长久保留以便将 来有用，这是测试框架的目标之一。同时，对象开发人员习惯于对象，因此把测试作为对象就能达到让编写测试代码更具吸引力的目的。 　　在这 里，命令模式（command）满足我们的需要。该模式把请求封装成对象，即为请求操作生成一个对象，这个对象中有一个“执行（execute）”方法。 命令模式中，请求者不是直接调用命令执行者，而是通过一个命令对象去调用执行者，具体说，先为命令请求生成一个命令对象，然后动态地在这个命令对象中设置 命令执行者，最后用命令对象的execute方法调用命令执行者。这是TestCase类定义代码：〔此处译者有添加〕 　　public abstract class TestCase implements Test { 　　... 　　} 　　因为我们希望通过继承复用这个类，我门把它定义成“public abstract”。现在我们先不管它实现Test接口，在此时的设计里，你只要把TestCase看成是一个单个的类就行了。 　　每个TestCase有一个名字属性，当测试出现故障时，可以用它来识别是哪个测试用例。