X++ attributes are a new feature in Microsoft Dynamics AX 2012 and are described in Chapter 4. This section describes how you can use the predefined test attributes in the SysTest framework to improve development and execution flexibility.

Five SysTest attributes are provided as part of the framework. These attributes are described in Table 15-1.

Naming conventions were used heavily in previous versions of the SysTest framework to indicate the intent of a class or a method. A class naming convention of <TargetClass>Test was used to specify the code class targeted for code coverage collection. (You could also override the testsElementName method on your test class as an alternative to this convention.) All methods intended to be test methods in a SysTestCase-derived class had to start with the string test.

By using SysTestTargetAttribute and SysTestMethodAttribute, you can be more explicit in your unit test code. The following code examples show you how to use these attributes.**#pg529**

[SysTestTargetAttribute(classStr(Triangles), UtilElementType::Class)]
public class TrianglesTest extends SysTestCase
{
}

[SysTestMethodAttribute]
public void testEQUILATERAL()
{
    Triangles triangle = new Triangles();
    this.assertEquals(TriangleType::EQUILATERAL, triangle.IsTriangle(10, 10, 10));
}

The new predefined attributes provide the capability to create filters so that you can execute specific tests shown in Figure 15-1. You can use SysTestCheckInTestAttribute, SysTestNonCheckInTestAttribute, and SysTestInactiveTestAttribute for this purpose. In the Parameters form, which you access from the unit test toolbar, you can select the filter you want to use when running tests. For information about how to create a filter, see the following section.

Figure 15-1. Filter list in the Parameters form.

Executing regression tests when code is checked in to version control is a great way to keep your code base at a high level of quality. But you don’t always want to run all tests because the amount of time required for execution might become an issue. This is where the attributes SysTestCheckInTestAttribute and SysTestNonCheckInTestAttribute are useful. For more information about version control, see Chapter 2.

Use the following steps to specify which tests are executed on check-in:

On your next check-in, the appropriate tests will execute, and the results will be displayed in an Infolog message.

The predefined test attributes described in the previous section are a good starting point for being more explicit in your test code and for organizing your tests. A well-organized strategy for using test projects can also be helpful. But there’s a good chance that you will want to take test organization a step further for your development projects. Fortunately, you can extend the test attribute capabilities by creating your own attributes and filters.

As noted earlier in this chapter, the SysTest framework can be useful for both class-level unit testing and for integration tests on business logic that spans classes. However, it might be useful to be able to run just the integration tests in certain scenarios because they are more functionally oriented. For example, you might want to run only the integration tests when moving code from your test environment into preproduction.

This section demonstrates how you can create a new attribute and a corresponding filter to use on integration tests.

First, create the new attribute. This is quite straightforward because you only need to create a class that inherits from SysTestFilterAttribute.

class SysTestIntegrationTestAttribute extends SysTestFilterAttribute
{
}

You can now use this attribute on a new test method as follows:

[SysTestMethodAttribute,
SysTestIntegrationTestAttribute]
public void testIntegratedBusinessLogic()
{
    this.assertFalse(true);
}

**#pg531**While this attribute is informative to anyone reading the test code, it isn’t useful for execution until you also enable it in the Filter drop-down list for test selection. To do this, you need to implement a test strategy for the IntegrationTestAttribute. The term “strategy” is used because the test strategy is implemented following the Strategy design pattern.

First, extend the SysTestFilterStrategyType enumeration with an additional element, as shown in Figure 15-2. Remember to set an appropriate label on the Properties sheet.

Figure 15-2. Extension to the SysTestFilterStrategyType enumeration.

Next, implement the strategy in a class with the same name as the enumeration element name. This class inherits from SysTestFilterStrategy and has a class declaration, as shown in the following example:

class SysTestFilterIntegrationTestsStrategy extends SysTestFilterStrategy
{
}

The most straightforward way to implement this strategy is to follow the pattern in one of the other SysTestFilter<attribute>TestsStrategy classes. You need to implement only two methods in this case.

The construct method returns a new instance of the class. You will use this method shortly.

public static SysTestFilterIntegrationTestsStrategy construct()
{
    return new SysTestFilterIntegrationTestsStrategy();
}

The work in this class is being done in the isValid method. This method determines if a test method should be included in the list of selected tests. For SysTestFilterIntegrationTestsStrategy, here is the implementation.**#pg532**

public boolean isValid(classId _classId, identifierName _method)
{
    SysDictMethod method;
    DictClass dictClass;

    method = this.getMethod(_classId, _method);
    if (method)
    {

        //
        // If the test method has the integration attribute, include it.
        //
        if (method.getAttribute(attributestr(SysTestIntegrationTestAttribute)))
        {
            return true;
        }
    }

    //
    // If the test class has the integration attribute, include it.
    //
    dictClass = new DictClass(_classId);
    if (dictClass.getAttribute(attributestr(SysTestIntegrationTestAttribute)))
    {
        return true;
    }
    return false;
}

There is one last thing to do to enable the new integration test attribute. The newType method in the SysTestFilterStrategy class creates the appropriate type based on the selection in the Filter list and must have an additional case added to it, as shown in the following example:

public static SysTestFilterStrategy newType(SysTestFilterStrategyType _type)
{
    SysTestFilterStrategy strategy;

    switch (_type)
    {
              <snip - non essential code removed>
        // Create an integration test strategy
        case SysTestFilterStrategyType::SysTestFilterIntegrationTestsStrategy:
            strategy = SysTestFilterIntegrationTestsStrategy::construct();
            break;**#pg533**
        default:
            throw error(error::wrongUseOfFunction(funcname()));
    }

    strategy.parmFilterType(_type);
    return strategy;
}

The Integration Tests option is now available in the Filter list (Figure 15-3) and, when selected, will run only those test methods attributed with SysTestIntegrationTestAttribute.

Figure 15-3. A filter list with a custom filter.

The quality plan for your project should not be focused on testing alone. On the contrary, many factors can have a bigger impact on the quality of the project than the amount of testing done. One key quality factor is configuration management. With the Visual Studio ALM solution, you can track all of the significant artifacts in your software development process. You can drive higher quality in your projects by adopting the ALM solution throughout your project.

Figure 15-4 describes an end-to-end feature development cycle involving Simon, a functional consultant, and Isaac, an IT developer. As you can see, the process involves tracking requirements, test cases, source code, builds, and bugs. Many of these items are tracked in Team Foundation Server (TFS). It also describes traceability between these artifacts. You could also incorporate work items into the process for improved project management.**#pg535**

Figure 15-4. Feature development cycle.

In a rapidly changing environment like most Microsoft Dynamics AX projects, an agile development approach is often the best development methodology. One agile development practice that is particularly helpful in ensuring quality is acceptance test driven development (ATDD). ATDD involves defining the critical test cases, the acceptance test cases, ahead of the development effort as a requirement. (The term “requirement” is used generically here. The requirement can be a user story, a feature, or another artifact that describes functionality that is valuable to a customer.)

Acceptance test cases frequently exercise the primary flows for a requirement. Additional test cases are required to fully test the requirement. Acceptance test cases should be a collaborative effort between the developer, the tester, and the author of the requirement. A significant benefit of this collaboration is clarity because the individuals involved frequently have different, unstated versions of how they expect the requirement to be implemented.

While the requirement should be free of implementation details, the acceptance test cases must have some implementation details to make them useful—but not too many. Figure 15-5 shows a sample acceptance test case for a feature described in the previous section—executing unit tests when code is checked in. The test case specifies details such as the forms that are expected to be used, but it doesn’t specify the exact field names.

Figure 15-5. Acceptance test case.

After you create the test, link it to the requirement on the Tested User Stories tab. (In this example, a user story is the requirement.) The Add Link form will look like Figure 15-6 after linking.**#pg536**

Figure 15-6. Requirement linked to test case.

By linking the test case to the requirement, you can use a nice feature in Microsoft Test Manager, the capability to build test plans based on requirement-based test suites. By specifying the requirement using the Add Requirements button in the Microsoft Test Manager Plan area, you pull in all test cases that are linked to the requirement.

With shared steps, you can reuse the same steps in multiple test cases. Think of shared steps as subroutines for your manual test cases. Using this capability appropriately is a big step toward long-term maintainability of your test cases.

A prime opportunity for using shared steps is to get the application into a known state at the start of each test case. For Microsoft Dynamics AX tests, starting the application through the command line and using command-line options to initialize the application for testing is an excellent strategy.

Here’s an example of how to start Microsoft Dynamics AX and run a job to initialize data. First, create an XML file, fminitializedata.xml, that you will reference in the command line and save it in a well-known location.**#pg537**

<?xml version="1.0" ?>
<AxaptaAutoRun
    exitWhenDone="false"
    logFile="c:AXAutorun.log">
        <Run type="job" name="InitializeFMDataModel" />
</AxaptaAutoRun>

Now the application can be started from the Run… dialog box with the following command string: ax32.exe -StartUpCmd=AutoRun_c:fminitializedata.xml.

You can incorporate this command line into a Launch AX And Set Start Location shared step along with some basic navigation so that the test case always starts from a known location, as shown in Figure 15-7.

Figure 15-7. Shared step.

Microsoft Test Manager includes basic record-and-playback capability. Because of the focus on the manual tester, record and playback is not intended for end-to-end, push-button automation where a test is fully automated. Instead, a manual tester can use this functionality to “fast-forward” through the routine portion of a test case to get to the interesting part, where validation is required and exploratory testing drives the effective discovery of bugs.

**#pg538**Shared steps are a great starting point for building efficiency into your manual testing through fast-forward capabilities. Microsoft Test Manager can record a shared step independently (Organize > Shared Steps Manager > Create Action Recording). The actions recorded for the shared step can be used in all test cases that use those actions. You can also optimize the playback by using the most efficient and reliable actions.

With its long command line and the need to consistently be in a known state, the Launch AX And Set Start Location shared step shown in Figure 15-7 is a great candidate to record. To make this as efficient and reliable as possible, you can perform the following steps:

The left side of Figure 15-8 shows what Microsoft Test Manager looks like after recording the shared step. The right side of Figure 15-8 shows a test case using the shared step. Notice the green arrow in the highlighted first step. This gives you the option to fast-forward through the shared step.

Creating detailed, step-by-step test cases early in the development process can become counterproductive as the application evolves to its final form. A better alternative is to develop your test cases in phases:

Figure 15-8. Microsoft Test Manager showing a recorded step and a test case that uses it.

Scenario tests are valuable for business applications because long workflows are typical of business processes. Mapping these long scenarios to a test case can be challenging because you don’t want a test case that has dozens of steps.

**#pg540**Microsoft Test Manager solves this problem by providing the capability to define the order of test cases within a test suite. Figure 15-9 shows an example of a human resources end-to-end scenario that is divided into many short test cases and then ordered within a test suite.

Figure 15-9. Test suite with multiple test cases.

The Visual Studio 2010 ALM solution also includes Team Foundation Build, a workflow-enabled system that you use to compile code, run associated tests, perform code analysis, release continuous builds, and publish build reports. You can apply Team Foundation Build to Microsoft Dynamics AX projects. While the build process is beyond the scope of this chapter, running tests from Team Foundation Build is not.

**#pg541**Tests that are executed as part of a build process must be fully automated. Given this requirement, the starting point should be tests written using the SysTest framework. Fortunately, some tools are in place to enable execution of Microsoft Dynamics AX SysTest test cases from the Visual Studio environment.

The first step is for the SysTest framework to provide results in a format that Visual Studio expects, specifically the TRX output format. There are two pieces of good news here. First, the SysTest framework provides an extensible model for test listeners for results. Second, the Microsoft Dynamics AX partner ecosystem has provided a sample TRX implementation on CodePlex using the Test Listeners capability. The SysTestListenerTRX package for Microsoft Dynamics AX 2012 can be downloaded from http://dynamicsaxbuild.codeplex.com/releases.

The second step is to be able to initiate tests from Visual Studio. The Generic Test Case capability was developed to wrap an existing program. This is perfect for this situation because Microsoft Dynamics AX can run a test project from the command line and specify the Test Listener and the location of the output file.

Suppose you want to execute all tests marked with SysTestIntegrationTestAttribute that were created earlier in this chapter. After downloading and installing the SysTestListenerTRX package from the link shown earlier, do the following:

Figure 15-10. Test settings.

When you run all tests in the solution from Visual Studio (Click the Test menu > Run > All Tests In Solution), you will see the Microsoft Dynamics AX client open and then close. The results for this example are shown in Figure 15-11. Two tests were marked with SysTestIntegrationTestAttribute, and both passed.

A typical Microsoft Dynamics AX development project has four unique environments: development, test, preproduction, and production. This section provides a brief description of each environment and discusses how to apply the test tools in this chapter to each of them.**#pg543**

Figure 15-11. Test results.

The development environment is where developers are actively contributing code. A quality development process focuses on ensuring quality as close to the source of possible defects as possible. This is an excellent opportunity to use the SysTest framework for developing unit tests for new classes or methods and integration tests for basic multi-class interaction. Over time, these automated tests can form a regression suite that can be executed during the check-in and build processes as described in this chapter. The ATDD process described earlier in this chapter for validating requirements should also be applied in the development environment, so the testers on the project need to be involved during the development phase, optimally using the Visual Studio 2010 test tooling.

Broader testing is targeted for the test environment. Varying levels of integration testing are typical of this environment, with a strong focus on ensuring that business processes are functioning end to end. Creating test suites that use ordered test cases in Microsoft Test Manager is a good approach here. This is a good opportunity to evolve the detail of the test cases, using a well-designed approach for shared steps to minimize duplication across the suites. As the product changes and new builds are created, the SysTest regression suite should continue to be executed.

**#pg544**User acceptance testing (UAT) is the primary activity in the preproduction environment. The Microsoft Test Manager test suites developed for the test environment can form the basis for the UAT performed by users in the business. The data that you use for this testing should be a snapshot of the production data.

If all goes well in the previous environments, the code is deployed to production. To minimize downtime, only a cursory check, or smoke test, is performed after the new code is deployed. This typically is a manual test case defined by the business but exercised by the IT specialists performing the deployment. Once again, you can use Microsoft Test Manager to define the test case and provide an execution environment with recorded steps for auditing and debugging purposes.

To ensure that you have a quality, comprehensive test plan in place, you may want to review additional documentation that contains processes and guidelines for quality-focused development. For more information, see the Microsoft Dynamics AX 2012 white paper “Testing Best Practices,” available at http://www.microsoft.com/download/en/details.aspx?id=27565, and Microsoft Dynamics SureStep methodology, at http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=5320.