AX 单元测试框架

原文：http://msdn.microsoft.com/en-us/library/aa874515.aspx

单元测试框架

AX的MorphX IDE非常紧密地集成了单元测试框架。对于测试驱动开发（TDD）而言，这一集成是非常重要的，因为对于所要测试的每一个特性都可以创建对应的测试单元。更多TDD的信息可以查看微软的测试驱动开发向导。（我个人更建议你看看浅谈测试驱动开发）

什么是单元测试

---

一个单元测试就是一段代码，它用于测试实现某一特征（可理解为功能）的代码（下文中统一称作：特征代码）是否被正确实现。如果你遵循TDD原则的话，最佳实践是开发人员首先写单元测试，然后再写特征代码。这样可以将开发的重点放在特征代码的调用及创建更为友好的API上。在单元测试框架中，一个单元测试，包括测试用例、如何使用数据执行测试用例以及组织测试用例。一个测试用例既一个继承自SysTestCase的子类。你可以为每一段特征代码添加测试方法，可以在代码发送修改的使用执行测试用例。

命名规则

被测试的类的名字加test既是对应测试用例的名字，按照这样的规则，AX会自动关联类及测试用例，并且在执行测试用例时单元测试框架会统计测试的代码覆盖率。如果这样的命名规则不能满足你的需要，你可以选择下面的备选方法：

 

命名规则

描述

重写testsElementName方法

关联被测试的类。

如果你不想使用测试用例默认的命名规则（既类名+test），你可以选择重写该方法来实现测试用例与被测试类之间的关联。

重写testsElementType方法

关联正确的被测试对象类型

如果你要测试非class类型的对象，就需要重写该方法。比如，如希望测试一个表。

如果统计代码覆盖率功能被激活，并且测试用例中被测试对象的类型和名字被正确赋值，代码覆盖率才能够正常工作。

例子

这个例子演示如何声明一个测试类。被测试的类名字为Employee。

class EmployeeTest extends SysTestCase{}

 

测试用例创建向导

下面的列表列举了创建测试用例的指导方针：

• 你以被测试类名+test来命名你的测试用例.
• 以有意义的方式来分组测试用例。不要创建很多功能相似的用例，将用例分组可以帮助识别冗余。
• 不要为每一个方法和属性都创建测试用例。这样会导致很多不必要的简单测试用例，会加重你的工作负担。
• 重构你的测试用例以使他简单。如果测试代码被多个测试方法共享，可以创建一个新的私有方法来包含这段代码。
• 避免依赖和过度复杂，最后避免不同单元测试间共享测试代码。

可用的测试方法

单元测试框架提供了很多方法（断言方法，既判断是与不是的方法）来满足你的测试需要。创建测试用例时首先创建一个继承自SysTestCase的子类。

下面的列表列举了使用断言时的一些指导方针：

• 对已测试的条件不需要断言
• 在希望得到特定预期值的时候使用断言
• 在比较字符串时使用label而不是静态字符串

下表描述了SysTestCase类所包含的断言方法，更多的信息请点击每一个方法上的链接。

方法

描述

assertEquals

测试两个值是否相等

assertFalse

测试值是否为false

assertNotEqual

测试两个值不相等

assertNotNull

测试值不为null

assertNotSame

测试对象引用不相同

assertNull

测试值为null

assertRealEquals

测试实数与特定值的差异是否在一定范围之内

assertSame

测试对象引用相同

assertTrue

测试值为true

fail

允许你创建自己的判断逻辑，并调用fail方法与单元测试框架集成

parmExceptionExpected

测试一个预期的异常

 

以下部分介绍单元测试框架的内容。

单元测试工具栏

---

单元测试工具栏可以用于选择一个测试用例，运行该测试用例，查看结果及运行细节。通过该路径访问单元测试工具栏：AX工具栏/Tools/Development tools/Unit test/Show toolbar。你也可以通过另外的方法访问单元测试工具栏：在测试用例上右键单击/Add-ins/Run tests。

单元测试详细内容

---

单元测试详细内容提供如下信息：测试是否通过，什么时候，谁创建了该测试用例，代码覆盖率已经环境变量。你可以通过点击单元测试工具栏的Details按钮来访问这些细节。

代码覆盖率

在测试执行过程中，运行的每一行都会被记录。你可以查看被测试代码如何被测试及那些没有被覆盖的代码，从而改进测试用例。

你必须激活捕捉测试覆盖率的功能选项。测试用例执行以后代码覆盖率是通过Form来显示的。关于如何激活捕捉代码覆盖率选项及如何查看代码覆盖率请查看：如何访问代码覆盖率详细信息。

测试结果输出

单元测试框架提供了多种报表选项，称之为监听器。默认情况下，但你通过单元测试工具栏运行测试用例时，数据库被作为监听器。你也可以添加其他的监听器。更多关于如何选择其他的监听器请查看如何显示测试用例结果。下表列举了单元测试框架支持的监听器：

• 数据库
• Infolog
• Infolog (result only)
• Print窗口
• 进度条
• Text 文件
• XML 文件

组织测试用例

---

但测试用例的数量不断增加时，如何组织测试用例变得非常重要。测试用例可以分组为测试套件（test suites）。一个测试套件可包含一个或多个测试用例以及测试套件。这样，测试用例就可以被按层次结构分组。更多关于如何创建测试套件及测试项目的信息，请查看如何组织测试用例。

装载和拆卸共享数据

你可以在两个级别上装载和拆卸共享数据，测试用例级别和测试套件级别。装载和拆卸共享数据带来的好处远不止允许你以更有意义的方式组织测试用例。如果你的测试使用相同的装载和拆卸代码，可以将这些代码写在测试用例的setUp和tearDown方法中。测试框架会确保每个测试方法执行时，都会调用装载和拆卸方法。

另一种情况是装载和拆卸代码只在整个测试类执行的开始和结束执行，既先执行装载，然后运行所有测试方法，最后拆卸。这种情况下你可以将装载和拆卸代码写在测试套件的setUp和tearDown方法中。

更多信息请参考如何为测试用例创建装载和拆卸逻辑。

隔离测试用例

根据测试用例对数据修改的不同，需要隔离测试用例的级别也不同。单元测试框架提供了4种测试套件，分别提供不同界别的隔离。下表描述了测试套件及其隔离级别。

测试套件

隔离级别描述

SysTestSuite

没有任何隔离。默认的测试套件。

SysTestSuiteCompanyIsolateClass

为测试用例构造一个空的公司账号，所以测试方法都在该公司下运行，最后在删除该账号。

SysTestSuiteCompanyIsolateMethod

为每一个测试方法创建一个空的公司账号，在该方法执行完后删除该账号。这一级别提供了最好的隔离，但是这是以一定的性能损耗为前提的。

SysTestSuiteTTS

每一个测试方法都被以一个交易来进行封装。在测试方法执行完后，交易被终止而不会被提交。

这一级别表现很好但有两点限制：

1.       不能用于需要提交数据的测试

2.       不支持parmExceptionExpected

 

 

例子

下面的代码演示了如何使用隔离。你需要在你的测试用例中重写createSuite方法来返回合适的测试套件。

class SysTestSuite createSuite(){ // Set the isolation level to construct a company account for the // entire test class. return new SysTestSuiteCompanyIsolateClass(this);}

 

更多关于创建、运行和评估测试用例的信息，请查看演示：使用单元测试框架测试类。