Breaking news from around the world
Get the Bing + MSN extension
Now Available in Community - MBAS 2019 Presentation Videos
Catch the most popular sessions on demand and learn how Dynamics 365, Power BI, PowerApps, Microsoft Flow, and Excel are powering major transformations around the globe. | View Gallery
2019 release wave 2 Discover the latest updates to Dynamics 365Release overview guides and videos Release Plan | Early Access Availability
Ace your Dynamics 365 deployment with packaged services delivered by expert consultants. | Explore service offerings
Connect with the ISV success team on the latest roadmap, developer tool for AppSource certification, and ISV community engagements | ISV self-service portal
The FastTrack program is designed to help you accelerate your Dynamics 365 deployment with confidence.
FastTrack Program | Finance TechTalks | Customer Engagement TechTalks | Talent TechTalks | Upcoming TechTalks
Like any other code, AL code can be flawed and break during refactoring. To prevent manual testing, each time you make the smallest change in code, it is necessary to write AL automated tests. AL automated tests are pivotal to ensure that your code works correctly after refactoring or addition of new functionality.
In this article, we are going to talk more about how you should structure your AL automated tests instead of the code logic itself.
If you are using Docker as a platform where to hold databases meant for development, you will first need to import Testing toolkit. This is necessary so that you would have access to Assert codeunit. Assert codeunit is used to set conditions that check whether your code works as intended or not.
Follow these steps to import Testing Toolkit to your container:
Now you need to write all AL automated tests in separate codeunit, and to be able to do that, you need to set codeunit’s subtype to Test.
Each separate test needs to have an indication that it is a test. You can indicate that by writing [Test] before procedure.
The rest of the codeunit follows the same structure as regular codeunit, except for Assert before the end of the procedure.
Now you can declare Assert in local procedure variables or as a global variable.
This code, inside procedure, is used to set up the test itself. What goes into it depends on what exactly you are testing. In this example, the code check’s whether autofill code works correctly. It does that by initiating new entry, entering a value to “CodeField” field and activating OnValidate trigger. Then with Assert it checks if the field, which should be filled, is filled. The text “Field is empty” shows only if the test fails. This is the code bit that this test is testing:
You can also create procedures that are not tests. Just simply don’t indicate that it as a test.
In order to run AL automated tests that you have written, you have to publish your application, then go to “Test Tool” page, upload all “Test” codeunits and run them from there. The easiest way to access this page is to configure your launch.json so that startup page would be 130401.
When publishing your extension, be ready to be directed straight to the testing page, where you will need to upload all test codeunits. Complete this action by pressing Get test codeunits button:
When uploading all codeunits, you can either run only selected ones or all of them at once.
As you can see, next to failed test there is text, which you write in Assert. Additionally, all the changes made to the database, for example, new entries created, are deleted after all tests are done.
Let’s start with codeunits themselves. A good practice is to dedicate the whole codeunit to one part of your solution. You can split AL automated tests to different codeunits by code functionality, making tests library easier understandable and maintainable.
So, let’s say your solution creates new entries and post’s reports, then you create two different codeunits, one to test the functionality of entries creation and second to test posting functionality.
Inside these codeunits, you create tests themselves. Each test name should have an informative name, meaning, it should talk for itself. For example, if this test checks if a solution actually creates a new empty entry, then the name of this test should look something like this CreateNewEmptyEntry_Test. Some names can get really long, but don’t worry about that, it’s better to have longer, more clear names rather than short ones.
You should only put one Assert in one test. There’s no one stopping you from putting as many Asserts as you want, but that can be confusing since if at least one Assert fails, the whole test is marked as failed as well. In this case, it is best to go directly to tests and figure out what has failed and why it failed from Assert. This is the reason why it is important to have clear names, so in case of the failure, you could just look at the name and go straight to fixing it.
Your AL automated tests have to be specific, it should only be testing a certain part of your code and nothing else. Also, it is important to mention that it is always better to test each part of the functionality. For example, let’s say we have a table with three fields and a function in codeunit, which creates a new entry and fills the fields with random data.
We need to make a test to check this functionality so we have to create a codeunit for this whole functionality. The first test is to check if entry is created at all.
Then we need a test to check whether a value was added for the first field.
Finally, it is important to write a test to check if values were filled in the other two fields.
Divide your test solution to the smallest possible parts, it has to cover as much code as possible. It is recommended to write more than one unit test for each part of the code covering as many scenarios as possible. That way you not just stop possible bugs appearing after refactoring, but you may find bugs that you did not expect.
Your AL automated tests should be independent of any exterior programs or files. If it is not possible to avoid using an external file, try to find a way to create a dummy file inside the test and feed it as a real file to your solution. If your solution need’s to call for exterior services, create dummy services inside your test.
If you want your AL automated tests to be the most efficient it can be, it’s a good idea to make many “hooks” to which your test could attach to. That way you could test a tiny part of code instead of running the whole program, just do not forget to test whether a value was added to a field or not.
Hooks can be described as procedures that are global and can be called from a test itself. Another popular definition of hooks is extra procedures that call a procedure which you want to test.
Let’s repeat the most vital steps for test efficient writing:
All in all, sticking to the steps mentioned above will help you to write codeunits with AL automated tests, that will last a lifetime for your solution. How can you tell that your test is good enough? If your test doesn’t need fixing each time you make a change in your code, you can tap yourself on a shoulder! Don’t forget, practice makes perfect, and if you don’t have time to practice enough, leave it to professionals. We are always ready to help with any type of Microsoft Dynamics NAV Upgrade / 365 Business Central Upgrade!
The post AL Automated Tests: How to Write Your First Test? appeared first on Simplanova.
Business Applications communities