How to do unit testing in Microsoft Dynamics AX 2012 in the real world

Dynamics AX 2012 comes with support for unit testing.

In order to have meaningful tests, it is necessary to provide some test data (stored in tables in the database).

In order to get reproducible unit test results, we must have the same data stored in tables every time tests are run. Now the question is, how can we do this?

I found out that it is possible to set the isolation level for TestSuite SysTestSuiteCompanyIsolateClass . This will create an empty company and delete the company after the tests are completed. In the setup() method, I can populate my test data in tables with insert statements. This is great for small scenarios, but it becomes very cumbersome if you have a real life project.

I was wondering if there is anyone there with a practical solution on how to use the X ++ Unit Test Framework in a real world scenario. Any input is very welcome.

+5
source share
4 answers

I agree that creating test data in a new and empty company only works for fairly trivial scenarios or scenarios in which you yourself have implemented the entire data structure. But once existing data structures are needed, this approach can become very time consuming.

One approach that worked well for me in the past is to run unit tests in an existing company that already has most of the configuration data (e.g. financial setup, inventory setup, etc.) needed to run the test. The test itself is executed in the ttsBegin - ttsAbort , so the unit test does not actually create any data.

Another approach is to implement data provider methods that are non-specific for testing, but generate data that is often used in unit tests (for example, the method that creates the product). It will take some time to create a useful set of data transfer methods, but once they exist, unit test records become much faster. See SysTest V Part: Running a test (results, runners, and listeners) for how Microsoft uses this approach (or at least they used to return to 2007 for AX 4.0).

Both approaches can also be combined, you must call the data provider methods inside the ttsBegin - ttsAbort block to create the necessary data for the unit test only.

Another useful method is to use doInsert or doUpdate to create test data, especially if you are only interested in a few fields and do not need to create a fully reliable record.

+6
source

I think the unit test structure was belated. To really use it, Microsoft would have to provide unit test classes, and then when you tweak your code, you also tweak your unit tests.

Thus, without this, you, in fact, remain modular modules that try and include the base code along with your changes, which is a huge task.

Where I think you can really use it, there are isolated settings that perform some function and are not very dependent on the underlying code. As well as settings that integrate with external systems.

+4
source

Well, from my point of view, you cannot use more than specified in the standard structure. What you can do is more about release management. You can set up an integration environment with target data and push your night model into this environment at the end of the build process, and then run your tests. Yes, it will take more effort to set up and save, but this is the only solution I've seen so far to have a large and consistent set of data to run unit tests or integration.

+3
source

In order to have meaningful tests, it is necessary to provide some test data (stored in tables in the database).

As someone else has pointed out, I was better off using an existing company for data. In my case, several existing companies.

To get reproducible unit test results, we need to have the same data stored in tables every time tests are run. Now the question is, how can we do this?

We have built-in test assistants that help us β€œrun the test” by automating what a person will do - let you archive your application for verification. Essentially, our test class uses helpers to run the test, and then provides most of the value to validate the data that it created.

I found out that it is possible to set the isolation level for TestSuite for SysTestSuiteCompanyIsolateClass. This will create an empty company and delete the company after the tests have been run. In the setup () method, I can fill out my test data in tables by using insert statements. This is great for small scenarios, but cumbersome very quickly if you have a real life project.

I did not find this practical in our situation, so we did not use it.

I was wondering if there is anyone there with a practical solution on how to use the X ++ Unit Test Framework in a real world scenario. Any input is very welcome.

We used the testing platform as described above and it works for us. the key is to find the right scripts for testing, it also provides a good basis for writing test classes.

0
source

All Articles