How it works...

Most of the code we wrote is relatively straightforward, but it can be a little verbose. The normal pattern for writing tests is to write them as the main code is written, starting with blank methods for the acceptance criteria specified in the technical requirements augmented with other tests that seem necessary. Often, we write tests in order to debug the code we are writing, which can easily be done by choosing Debug selected tests.

There are a few points that need explaining, the first being the way data is handled. When a test case is run, it uses a partition to segregate the data it creates and will tear it down once the test has completed. This occurs for each test. We must not assume an order in which the tests are run, or assume we can use data that's been created in another test method.

The partition is a legacy feature from Dynamics AX 2012 and is a field that's used to hard-partition data as the boundaries between companies are relaxed. This partition key is now used solely for testing scenarios.

When the project was created, we referenced ApplicationFramework and TestEssentials. The discovery process works by looking for a class in the current project that extends SysTestCase and for methods that have the SysTestMethod attribute. The test method must be public, return void, and have no parameters. They should start with (or at least contain) the word test and reference the method in the class we are testing. If a test method does not appear in the Test Explorer, check that the class extends SysTestCase and that the test methods have the SysTestMethod attribute. The test will often appear before the project is built and will fail with a suitable message, should the test be run prematurely.