Testing the Application
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.
Before you release your Microsoft Dynamics NAV application you must test the functionality. Testing is an iterative process. It is important to create repeatable tests, and it is helpful to create tests that can be automated. This topic describes the features in Microsoft Dynamics NAV 2009 SP1 that help you test the business logic in your application and some best practices for testing your Microsoft Dynamics NAV application.
The features in Microsoft Dynamics NAV 2009 SP1 do not provide assistance for testing the UI in your application.
Microsoft Dynamics NAV 2009 SP1 includes the following features to help you test your application:
Test runner 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:
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:
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.
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.
Handles MESSAGE statements
Handles CONFIRM statements
Handles STRMENU statements
Handles specific forms or pages that are not run modally
Handles specific forms or pages that are run modally
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.
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.