NAV 2017 includes the enhanced C/AL Testability feature set designed to support C/AL test-driven development. Test-driven development is an approach where the application tests are defined prior to the development of the application code. In an ideal situation, the code supporting application tests is written prior to, or at least at the same time as, the code implementing the target application function written.

Advantages of test-driven development include the following:

• Designing testing processes in conjunction with functional design
• Finding bugs early
• Preventing bugs reaching production
• Enabling regression testing which prevents changes from introducing new bugs into previously validated routines

The C/AL Testability feature provides test specific types of Codeunits-Test Codeunits and Test Running Codeunits. Test Codeunits contain Test methods, UI handlers, and C/AL code to support Test methods including the AssertError function. Test Runner Codeunits are used to invoke Test Codeunits, for test execution management, automation, and integration. Test Runner Codeunits have two special triggers, each of which run in separate transactions, so the test execution state and results can be tracked. The two triggers are:

• OnBeforeTestRun: This is called before each test. It allows defining, via a Boolean, whether or not the test should be executed.
• OnAfterTestRun: This isis called when each test completes and the test results are available. It allows the test results to be logged, or otherwise processed via C/AL code.

Among the ultimate goals of the C/AL Testability feature are the following:

• The ability to run suites of application tests both in automated mode and in regression tests:
  • Automated means that a defined series of tests could be run and the results recorded, all without user intervention.
  • Regression testing means that the test can be run repeatedly as part of a new testing pass to make sure that features previously tested are still in working order.
• The ability to design tests in an atomic way, matching the granularity of the application code. In this way, the test functions can be focused and simplified. This allows for relatively easy construction of a suite of tests and, in some cases, reuse of test codeunits (or at least reuse of the structure of previously created Test Codeunits).
• The ability to develop and run the Test and Test Runner Codeunits within the familiar C/SIDE environment. The code for developing these testing codeunits is C/AL.
• The TestIsolation property of TestRunner Codeunits allow tests to be run, then all database changes are rolled back so that no changes are Committed. After a test series in this mode, the database is the same after the test as it was before the test.
• Once the testing codeunits have been developed, the actual testing process should be simple and fast in order to run and evaluate results.

Both positive and negative testing is supported. Positive testing looks for a specific result, a correct answer. Negative testing checks that errors are presented when expected, especially when data or parameters are out of range. The testing structure is designed to support the logging of test results, both failures and success, to tables for review, reporting, and analysis.

A function property defines functions within Test Codeunits to be Test, Handler, or Normal. Another function property, TestMethodType, allows the definition of a variety of Test Function types to be defined. TestMethodType property options include the following handlers that are designed to handle User Interface events without the need for a user to intervene:

• MessageHandler: This handles the MESSAGE statement
• ConfirmHandler: This handles CONFIRM dialogs
• StrMenuHandler: This handles STRMENU menu dialogs
• PageHandler: This handles Pages that are not run modally
• ModalPageHandler: This handles Pages that are run modally
• ReportHandler: This handles Reports
• RequestPagetHandler: This handles the Request Page of a specific Report
• FilterPageHandler: This handles Filter Pages generated by a FilterPageBuilder data type
• HyperlinkHandler: This handles hyperlinks that are passed to the HYPERLINK function
• SendNotificationHandler: This handles the new NAV 2017 Notifications
• RecallNotificationHandler: This handles the recall of the new NAV 2017 Notifications

The C/SIDE Test Driven Development approach should proceed along the following steps:

1. Define an application function specification.
2. Define the application technical specification.
3. Define the testing technical specification including both Positive and Negative tests.
4. Develop Test and Test Running codeunits (frequently, only one or a few Test Running codeunits will be required).
5. Develop Application objects.
6. As soon as feasible, run Application object tests by means of the Test Running codeunits, and log test results for historical and analytical purposes.

7. Continue the development-testing cycle, updating the tests and the application as appropriate throughout the process.
8. At the end of successful completion of development and testing, retain all the Test and TestRunning codeunits for use in regression testing the next time the application must be modified or upgraded.

With the latest product media, Microsoft released a full set of approximately 16.0000 regression tests written by Microsoft for NAV 2017 using the NAV Testability tools. These are the tests that the NAV product developers used to validate their work. The number of tests that apply to a specific situation depends on the local version and specific features involved. Make sure your license is updated too.

Included are the regression tests and various tools to manage and execute tests built on top of the testability features released for Microsoft Dynamics NAV. Also included is a coverage tool and guidance documentation to create our own tests and integrate those with the Microsoft provided tests. This allows us to do full regression testing for large modifications and ISV solutions.