使用JUnit高效完成功能测试(3)

　　Saxon中有个相对简单的例子。已有XML文件和XPath表达式的情况下，Saxon可以执行表达式并返回匹配列表。Saxon中的XpathExample样本类就是用来执行这种任务的。基于以上分析，可以设计如下的测试流程：

　　public void testXPathEvaluation() {

　　//initialize

　　XPathEvaluator xpe = new XPathEvaluator(

　　new SAXSource(new InputSource("/path/to/file.xml")));

　　XPathExpression findLine =

　　xpe.createExpression("/some/xpath[expression]");

　　//work

　　List matches = findLine.evaluate();

　　//check

　　assertTrue(matches.count() > 0);

　　}

　　两次输入的都是字符串常量，输出的则是所匹配的列表，可以用来验证匹配结果的正确性。这些工作都由一行代码完成，这行代码只是简单地调用了被测试的方法。

　　另一种可能的情况是XPathEvaluator没有调用createExpression()方法。因为表达式不存在，这时可能会显示错误信息。

　　将输入的源文件名和表达式保留在测试用例中不是个好习惯。某些项目(服务器名、用户名和密码等)不应该出现在测试文件中，它们应该可以根据情况自由设置。并且，测试用例的设计应该方便测试驱动和测试数据的分离、测试驱动对大范围数据的可重用性和测试数据对测试驱动的可重用性。另一方面，不要将一个简单的测试用例实现设计地过于复杂。一般来说，测试用例已经说明了系统的大部分状态，并可对其进行参数描述，所以无需在测试中进行过于详细的参数描述。

　　许多代码段可能出现在不止一个测试用例中。有经验的面向对象开发人员会尝试对其进行重构并创建通用类和有效方法。有时候这样做非常有用，比如登录过程应该设计成所有测试用例可用的方法。 但是，不要过度设计测试，这些Java类仅仅是用来验证应用程序的功能行为而已。

　　测试用例是脆弱的。比如，如果开发人员更改了testXPathEvaluation测试中输入文件的位置，或者creatExpression方法签名有所变动，测试脚本就会失效。

　　对于应用程序的测试用例实现来说，大量的重复性工作与改动是不可避免的。因此，可跟踪性对于所有的测试用例都是至关紧要的。出现问题的时候，如果能为开发人员指出相应的测试用例说明和用例说明将有利于提高修正bug的速度。

　　因此，测试用例注释中应标明原始说明文档的引用位置。这可以是一个简单的代码注释，也可以对每条测试都注释相关用例和所测功能，这样当测试出现问题时开发人员就会收到一条相关信息。因此，在代码中加入参考并维护可追踪性是很重要的。

　　设计运行时事件表

　　要了解测试覆盖的范围，必须先了解所测试代码如何运行，以及各种静态类如何形成描述程序状态的动态对象图表。

　　有许多模拟这种行为的方法，包括Granovetter图和物件互动图。其基本思想是用图形化的方式研究代码以了解测试中涉及到的运行时部分。这些技术都可用运行时事件表(Runtime Event Diagrams)来描述，因为这些图表显示了程序运行时发生的事件，而非理论上类可以控制的事件。这些图表非常重要的原因包括：

　　首先，这些图表便于从高层上理解代码，并提供有用的说明文档。这个文档与代码的内联文档不同。这些图表显示代码的运行时表现，是产生代码功能的地方，也易于对系统的了解;大多数设计模式和架构在用对象和参考表示时要比用类和域表示容易得多。

　　另外，这些图表将测试执行的代码分类列表，并确定测试是否会受到将来对任意代码改动的影响。如果开发人员确定测试A是建立在B、C和D的基础上，她就可以确定如果对B、C或D做出改动就需要对A进行重新测试(确保向后兼容)。

　　以尽可能少的步骤模拟系统是个好方法。总的来说，实际调用与此无关，重要的是系统如何作为整体运作以获得预期目标。可以用简化的模拟系统实现这个目的，该系统只关心对象间的基本交互，并用自然语言描述交互中发生的事件。

　　做出运行时事件表后，就可以将其整合到类文档中。需要注意的是，为表添加一些限制可使其对类的修改更有弹性。首先，一般不能使用方法名，因为它们会随时间发生变化。取而代之的是更易理解的自然语言描述。其次，这些图表主要是关于系统中各部分的交互。这是高层架构上的设计方案，一般不会再做改动。最后，图表是建立在类型而非特定类的基础上。只要基本类型不变，为维持交互协议的正常运行，这些图表就不需要更新。

原文转自：http://www.uml.org.cn/Test/20111142.asp