One of the challenges of testing is maintaining repeatability. Quite often, we need to test several times using the same data, but the test changes the data. If we have a small database, we can always back up the database and start with a fresh copy each time. However, that can be inefficient and, if the database is large, impractical. If we are using the built-in NAV Test functions, we can roll back any database changes so the tests are totally repeatable. Another alternative is to conclude our test with an ERROR function to test and retest with exactly the same data.

The ERROR function forces a runtime error status, which means the database is not updated (it is rolled back to the status at the beginning of the process). This works well when our debugging information is provided by using the Debugger or any of the DIALOG functions just mentioned prior to the execution of the ERROR function. If we are using MESSAGE to generate debugging information, we could execute a CONFIRM immediately prior to the ERROR statement and be assured that all of the messages are displayed. Obviously, this method won't work well when our testing validation is dependent on checking results using Navigate or our test is a multistep process, such as order entry, review, and posting. In this latter case, only use of the built-in Test functions (creating Test Runner Codeunits, and so on.) will be adequate. However, in some situations, use of the ERROR function is a very handy technique for repeating a test with minimal effort.

When testing just the posting of an item, it often works well to place the test-concluding ERROR function just before the point in the applicable Posting codeunit where the process would otherwise be completed successfully. In order for the Rollback function to be effective, we must make sure there aren't any COMMIT statements included in the range of the code being tested.