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

单元测试框架

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

什么是单元测试

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

命名规则

@H_502_102@

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

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

例子

@H_502_102@

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

class EmployeeTest extends SysTestCase { }

测试用例创建向导

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

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

可用的测试方法

@H_502_102@

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

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

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

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

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

单元测试工具栏