原文：http://msdn.microsoft.com/en-us/library/aa874515.aspx
单元测试框架
AX的MorphX IDE非常紧密地集成了单元测试框架。对于测试驱动开发（TDD）而言，这一集成是非常重要的，因为对于所要测试的每一个特性都可以创建对应的测试单元。更多TDD的信息可以查看微软的测试驱动开发向导。（我个人更建议你看看浅谈测试驱动开发）
什么是单元测试
一个单元测试就是一段代码，它用于测试实现某一特征（可理解为功能）的代码（下文中统一称作：特征代码）是否被正确实现。如果你遵循TDD原则的话，最佳实践是开发人员首先写单元测试，然后再写特征代码。这样可以将开发的重点放在特征代码的调用及创建更为友好的API上。在单元测试框架中，一个单元测试，包括测试用例、如何使用数据执行测试用例以及组织测试用例。一个测试用例既一个继承自SysTestCase的子类。你可以为每一段特征代码添加测试方法，可以在代码发送修改的使用执行测试用例。
命名规则
被测试的类的名字加test既是对应测试用例的名字，按照这样的规则，AX会自动关联类及测试用例，并且在执行测试用例时单元测试框架会统计测试的代码覆盖率。如果这样的命名规则不能满足你的需要，你可以选择下面的备选方法：
| 命名规则 |
描述 |
| 关联被测试的类。 如果你不想使用测试用例默认的命名规则（既类名+test），你可以选择重写该方法来实现测试用例与被测试类之间的关联。 |
|
| 重写testsElementType方法 |
关联正确的被测试对象类型 如果你要测试非class类型的对象，就需要重写该方法。比如，如希望测试一个表。 |
如果统计代码覆盖率功能被激活，并且测试用例中被测试对象的类型和名字被正确赋值，代码覆盖率才能够正常工作。
例子
这个例子演示如何声明一个测试类。被测试的类名字为Employee。
测试用例创建向导
下面的列表列举了创建测试用例的指导方针：
- 你以被测试类名+test来命名你的测试用例.
- 以有意义的方式来分组测试用例。不要创建很多功能相似的用例，将用例分组可以帮助识别冗余。
- 不要为每一个方法和属性都创建测试用例。这样会导致很多不必要的简单测试用例，会加重你的工作负担。
- 重构你的测试用例以使他简单。如果测试代码被多个测试方法共享，可以创建一个新的私有方法来包含这段代码。
- 避免依赖和过度复杂，最后避免不同单元测试间共享测试代码。
可用的测试方法
单元测试框架提供了很多方法（断言方法，既判断是与不是的方法）来满足你的测试需要。创建测试用例时首先创建一个继承自SysTestCase的子类。
下面的列表列举了使用断言时的一些指导方针：
- 对已测试的条件不需要断言
- 在希望得到特定预期值的时候使用断言
- 在比较字符串时使用label而不是静态字符串
下表描述了SysTestCase类所包含的断言方法，更多的信息请点击每一个方法上的链接。
| 方法 |
描述 |
| 测试两个值是否相等 |
|
| 测试值是否为false |
|
| 测试两个值不相等 |
|
| 测试值不为null |
|
| 测试对象引用不相同 |
|
| 测试值为null |
|
| 测试实数与特定值的差异是否在一定范围之内 |
|
| 测试对象引用相同 |
|
| 测试值为true |
|
| 允许你创建自己的判断逻辑，并调用fail方法与单元测试框架集成 |
|
| 测试一个预期的异常 |
以下部分介绍单元测试框架的内容。
单元测试工具栏