How to Integrate Test Automation in Daily Development Practice

You've got this far into this book, so by now you have a clear notion on the needs for and benefits of test automation for Dynamics 365 Business Central. You have also already exercised designing and writing tests based on Section 3, Designing and Building Automated Tests for Microsoft Dynamics 365 Business Central. The next step is to bring into practice what you have learned.

But from reading the book, and understanding the matters discussed, and working on your first exercises, making it part of your daily work might still be a threshold to take. As mentioned earlier, test automation is a team effort. Therefore, in this chapter, we will elaborate on a number of best practices that might turn out to be beneficial for you and your team in getting test automation working:

• Casting the customer wish into ATDD scenarios...

Casting the customer wish into ATDD scenarios

Crucial to getting test automation into your daily development practices is the adoption of it by the team. Like requirements and application code, tests and test code should be owned by the development team; not just formally, but also actively. Good application code does not emerge from a single-lined customer wish, it derives from a well detailed and formalized customer wish. And the same applies to tests and test code.

As discussed in Chapter 4, Test Design, formalize your requirements by using the ATDD design pattern. Cast your customer wish in ATDD scenarios. Break down each wish into a list of tests, and make this your primary vehicle of communication for (1) detailing of your customer wish, (2) implementation of your application code, (3) structured execution of your manual tests, (4) coding of your test automation and (5)...

Taking small steps

As the saying goes, Rome wasn’t built in a day. Likewise, get to master test automation one step at a time. Learn and improve by doing the following:

• Start casting the customer wish into the scenarios that come to mind. Try to keep it simple. Preferably, you would like to get a full coverage right away, but as it is a team effort, they will help you to identify the holes, and fill them.
• Make use of my 4-steps recipe, create, embed, write, and construct, for the conception of the test code:

1. Create a test codeunit
2. Embed the customer wish into a test function
3. Write your test story
4. Construct the real code

• Get the test(s) run with every step performed, and as soon as the code is deployable. Do not wait until you’re finished, but verify your effort as soon as possible. See how your tests move from red to green.
• Take joy in testing the...

Making the test tool your friend

In Chapter 3, The Test Tool and Standard Tests, we introduced you to the test tool and we used it frequently during the work we did on the test examples. We applied it to test the test after having inserted a bug to let the verification error. Next to VS Code, your coding tool, and debugger, the test tool is your best friend. Keep it running while you develop, "do not wait till the code is ready, verify each atomic change by running the tests", as mentioned previously.

Create a specific test suite to hold the test codeunits that relate to the code you are working on. In most of your projects, it’s very likely, as with the LookupValue extension, that you end up with a bunch of test codeunits that will be executed within less than a minute. While working on a new test codeunit, create a new test suite to only hold that codeunit and...

Integrating with daily build

Where software development is about building applications that link and automate business processes, modern software development adds this to its own processes as follows:

• Sharing code in source code repositories that can be accessed and managed through APIs from anywhere
• Building your software from scratch at any time automatically
• Running an automated test run, triggered by the completed build, to show the validity of the rebuild software
• Deploying a build approved by the automated tests is automatic on a scheduled time
• Collecting all the results and statuses of the foregoing processes on a dashboard to inform the stakeholders about the sanity of the software

Contemporary development tools, such as Microsoft Azure DevOps, enable you to achieve this. The following screenshot shows a Azure DevOps dashboard integrating all of the preceding bullet...

Maintaining your test code

Like application code, test code is code, so handle it as application code should be handled, for example:

• It needs to be secured, ideally by means of a source code management tool
• It needs to be maintained and as any new customer wish will result in a change of the application code, it will most likely also change the test code
• It needs to be debugged, whether you like it or not, as any coding done by a developer potentially inserts new bugs
• It needs to be reviewed to assure that, like application code, it meets the coding standards

Extensions and tests

Before we conclude this chapter, a note must be made on how to organize your extension code with respect to application and test code.

If we take...

Summary

In this chapter, we paid attention to a number of best practices on how to embed test automation in your daily development practice. Get your functional peers writing ATDD scenarios to make use of the Excel sheet discussed. Do not overload yourself and your team and take small steps. Use the test tool next to your development tools and keep the tests running. Automate your development processes including running your tests. And last but not least, test code is code, so maintain it as you maintain your application code.

We’re on the verge of the last chapter, Chapter 9, Getting Business Central Standard Tests Working on Your Code, in which we will have a closer look at the tests provided by Microsoft and how we could also integrate this humongous collateral of standard tests.