MSDN Library
Servers and Enterprise Development
Microsoft Dynamics
Microsoft Dynamics NAV
Microsoft Dynamics NAV 2009 Developer and IT Pro Documentation
Development Considerations
Designing C/SIDE Applications

Testing the Application

How to: Create Test Codeunits and Test Functions
How to: Create Handler Functions
How to: Create a Test Runner Codeunit
Walkthrough: Testing Vendor Discount

Note
The content in this topic only applies to Microsoft Dynamics NAV 2009 SP1. For Microsoft Dynamics NAV 2009 content, see Developer and IT Pro Help for Microsoft Dynamics NAV 2009.

Note
The features in Microsoft Dynamics NAV 2009 SP1 do not provide assistance for testing the UI in your application.

Test Features

Microsoft Dynamics NAV 2009 SP1 includes the following features to help you test your application:

Test codeunits
Test runner codeunits
UI handlers
ASSERTERROR statement

Test Codeunits

You write test functions as C/AL code in the test codeunits. When a test codeunit runs, it executes the OnRun function and then executes each test function in the codeunit, records the outcome in a log, and displays the results in a message window. The outcome of a test function is either SUCCESS or FAILURE. If any error is raised by either the code that is being tested or the test code, then the outcome is FAILURE, and the error is included in the results log.

Even if the outcome of one test function is FAILURE, the next test functions are still executed.

The functions in a test codeunit are one of the following types:

Test function
Handler function
Normal function

For more information, see How to: Create Test Codeunits and Test Functions.

Test Runner Codeunits

You use test runner codeunits to manage the execution of test codeunits and to integrate with other test management, execution, and reporting frameworks. By integrating with a test management framework, you can automate your tests and allow them to run unattended.

Test runner codeunits include the following triggers:

OnBeforeTestRun
OnAfterTestRun

You can use these triggers to perform pre- and post-processing, such as initialization or logging test results. If you implement the OnBeforeTestRun trigger, then it executes before each test function executes. If you implement the OnAfterTestRun trigger, then it executes after each test function executes and additionally suppresses the automatic display of the results message.

For more information, see How to: Create a Test Runner Codeunit.

UI Handlers

To create tests that can be automated, you must handle cases when user interaction is requested by the code that is being tested. Microsoft Dynamics NAV 2009 SP1 provides UI handlers that run instead of the requested UI. UI handlers provide the same exit state as the UI. For example, a test function that has a FunctionType of MessageHandler handles MESSAGE function calls. If code that is being tested calls the MESSAGE function, then the MessageHandler function is called instead of the MESSAGE function. You write code in the MessageHandler function to verify that the expected message is displayed by the MESSAGE function.

The following table describes the available UI handlers.

Function type	Purpose
MessageHandler	Handles MESSAGE statements
ConfirmHandler	Handles CONFIRM statements
StrMenuHandler	Handles STRMENU statements
FormHandler	Handles specific forms or pages that are not run modally
ModalFormHandler	Handles specific forms or pages that are run modally
ReportHandler	Handles specific reports

You create a specific form handler for each form or page that you want to handle and a specific report handler for each report that you want to handle.

If you run a test codeunit from a test runner codeunit, then any unhandled UI in the test functions of the test codeunit results in a failure of the test. If you do not run the test codeunit from a test runner codeunit, then any unhandled UI displays as normal.

For more information, see How to: Create Handler Functions.

ASSERTERROR Keyword

When you test your application, you should test that your code performs as expected under both successful and failing conditions. To test how your application performs under failing conditions, you can use the ASSERTERROR keyword. The ASSERTERROR keyword specifies that an error is expected at run time in the statement that follows the ASSERTERROR keyword. If a simple or compound statement that follows the ASSERTERROR keyword results in an error, then execution successfully continues to the next statement in the test function. If a statement that follows the ASSERTERROR keyword does not result in an error, then the ASSERTERROR statement itself fails with an error, and the test function that is running produces a FAILURE result.

For more information, see C/AL ASSERTERROR Statements.

Testing Best Practices

We recommend the following best practices for designing your application tests:

Separate the test code from the code that is being tested. In this way, you can release the tested code to a production environment without releasing the test code.
Test code should test both positive and negative paths of the code that is being tested. The positive path validates that the code being tested works as intended under successful conditions. The negative path validates that the code being tested works as intended under failing conditions.
If a test has a SUCCESS result, then the test function should validate the result of application calls, such as return values, state changes, or database transactions.
If a test has a FAILURE result, then the test function should validate that the intended error messages are presented and that data has the expected values.
Tests should not require user intervention.
Test execution and reporting should be fast and capable of integrating with the test management system so that the tests can be used as check-in tests or other build verification tests, which typically run on unattended servers.