Вы находитесь на странице: 1из 7

Microsoft Dynamics AX Unit Test

Background
Unit test is based on Test-driven development (TDD), which drives the design of software and forces
decoupling of dependencies. This practice results a comprehensive suite of unit tests that can be run at
any time to provide feedback that the software is still working.

About Unit Test:


A unit test is code that verifies that feature code has been implemented correctly.
A unit test includes test cases.
A test case is a class that extends the (SysTestCase) class. You can add test methods to
test each requirement of the feature code.
Unit test provides constant feedback that each component is still working.
Unit test act as up-to-date documentation, unlike separate documentation.
Unit test Reduced debugging time.
Runs fast. If the tests are slow, they will not be run often.
Separates or simulates environmental dependencies such as databases, file systems,
networks, queues, and so on. Tests that exercise these will not run fast, and a failure does
not give meaningful feedback about what the problem actually is.
Its very limited in scope. If the test fails, it's obvious where to look for the problem. Use
few Assert calls so that the offending code is obvious. It's important to only test one thing
in a single test.
Runs and passes in isolation. If the tests require special environmental setup or fail
unexpectedly, then they are not good unit tests. Change them for simplicity and
reliability. Tests should run and pass on any machine. The "works on my box" excuse
doesn't work.
Often uses stubs and mock objects. If the code being tested typically calls out to a
database or file system, these dependencies must be simulated, or mocked. These
dependencies will ordinarily be abstracted away by using interfaces.
Clearly reveals its intention. Another developer can look at the test and understand what
is expected of the production code.

Naming Convention:
Name the test class by using the same name as the class it is testing followed by the word
Test.
This associates the test with the test case. It also enables the Unit Test framework to
collect code coverage data for the class.
Example
This example illustrates how to declare a test class. You can attach an attribute to the
class. This example attaches the (SysTestTargetAttribute) attribute to specify the
target class that is tested Employee. This is usually used to redirect the target to a
table.

Test Creation Guidelines:


You must name the test class using the same name as the class you are testing followed
by the word Test.
Group tests in a meaningful way. Do not create many similar tests, group them to
recognize redundancy.
Do not create one test per property or method. That will lead to many simple tests with an
unnecessary overhead when you set prerequisites.
Refactor your tests to be clean. If it is code shared by test methods on the same class,
create a new private method.
Avoid complexity and dependencies. It may be better to avoid code sharing in unit
testing.
Use attributes to add metadata to tests.

Run a Test Case:


The Unit Test framework provides the following ways to run a test case:

From the Unit Test toolbar.

Programmatically in code from the command prompt.

From the version control functionality during code check-in.

From the shortcut menu.

Test Attributes Available:


The Unit Test framework provides predefined attributes that you can attach to a test class or
test

method to provide

more

information. For

example,

you can attach the

(SysTestCheckInTestAttribute) attribute to indicate that the test case should be run as a


check-in specific test. You can define your own attributes.

Examples
To specify the target class for your test

This example illustrates how to attach an attribute to a class to specify that it should
be used for a test. This example attaches the SysTestTargetAttribute attribute to
specify the class that is tested is the Employee class.

To specify which methods on the unit test class are test methods

The following code example illustrates how to attach an attribute to a method to


indicate that it is a test method.

To specify which tests are tests for check in and integrate with a version control
system

You can run and classify the most critical test methods as check in tests. When you
set up the version control system, you can specify which test project to run during
check in. You can also specify whether to run all test methods, or only the test
methods that are marked as check in tests.

Test Methods Available:


The Unit Test framework provides methods that may meet your testing needs. When you
create a test case you will create a class and extend SysTestCase.

Do not assert conditions for which you already have a test.


Reference assertion methods where an expected value is specified.
Use labels instead of constant strings when you compare strings.

The following table describes the assertion methods on the SysTestCase class.

Unit Test Toolbar:


The Unit Test toolbar enables you to select a test case, run the test case, view the results, and
access additional details. Access the toolbar within Microsoft Dynamics AX with the
following steps, in a Development Environment, on the toolbar, click Tools, point to
Development tools, point to Unit test, and then click Show toolbar. You can also access the
Unit Test toolbar with the following steps, right-click the test case, point to Add-ins, and then
select Run tests. This will open the toolbar and click Run for you.

Create a Test Case:


When you create a test case, you will create a class that must follow the naming convention
best practice. Use the same name as the class that you are testing followed by Test. This will
associate the test class together with the class you are testing. In this procedure, you will
create a class named EmployeeTest that extends the SysTestCase class. The EmployeeTest
class will test the Employee class and the Name method. For the complete steps to create the
Employee class, see Walkthrough: Testing a Class Using the Unit Test Framework. The
following summarizes what the code should look like in the Employee class.

The Employee class should have the following code in the classDeclaration:

The new method should have the following code:

The name method should have the following code:

To create a test class:


1. Open the Development Workspace.
2. Press CTRL+D to open the Application Object Tree (AOT).
3. In the AOT, right-click the Classes node and click New Class.
4. Double-click Class1 to open the Code Editor.
5. In the Code Editor, extend SysTestCase by changing the class declaration to the
following code.

Adding a Test Method


In this procedure you will add a test method. You will do this by adding a method to the
EmployeeTest class. You will verify that the name of an employee is set when you use the
assertEquals assertion method.
To add a test method for the name requirement
1. In the AOT, right-click EmployeeTest, point to New, and then click Method.

2. In the Code Editor, change the method to the following code.

3. In the AOT, right-click the EmployeeTest class, point to Override method and then click
setup.
4. In the Code Editor, change the setup method to the following code.

5. In the AOT, right-click the EmployeeTest class, point to Override method and then click
createSuite.
6. In the Code Editor, change the createSuite method to the following code.

Next, you can run a test case and analyze the results.

Prepared by Ashraf : )

Вам также может понравиться