Chapter 9: 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 of 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.

Reading the book so far, trying to understand the matters discussed, and working on your first exercises, it might still be a threshold to take to make this all part of your daily work. 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. As such, we will cover the following topics:

• Casting the customer wish into ATDD scenarios
• Learning and improving...

Technical requirements

Like in the previous chapter, we will refer to the LookupValue extension. You can find its code on GitHub: https://github.com/PacktPublishing/Automated-Testing-in-Microsoft-Dynamics-365-Business-Central-Second-Edition.

In this chapter, we will continue with the code from Chapter 8, From Customer Wish to Test Automation – the TDD way: https://github.com/PacktPublishing/Automated-Testing-in-Microsoft-Dynamics-365-Business-Central-Second-Edition/tree/main/Chapter 08 (LookupValue Extension).

The final code for this chapter can be found in https://github.com/PacktPublishing/Automated-Testing-in-Microsoft-Dynamics-365-Business-Central-Second-Edition/tree/main/Chapter 09 (LookupValue Extension).

Details on how to use this repository and how to set up VS Code are discussed in Appendix, Getting Up and Running with Business Central, VS Code, and the GitHub Project.

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 an eventually well-detailed and formalized customer wish, aka requirements. And the same applies to tests and test code.

As discussed in Chapter 5, Test Plan and 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) up-to-date documentation of your solution. Your test automation...

Learning and improving by taking small steps

You get to master test automation one step at a time. Learn and improve by doing the following:

• Choose one of the when-to-use-automated-testing options as discussed in Chapter 1, Introduction to Automated Testing, that fits you and your team best, and/or gives the best return on investment, to start mastering test automation.
• Start casting the customer wish into the scenarios that come to mind. Try to keep it simple. Preferably, you would like to get full coverage right away, but as it is a team effort, chances are high that holes will be identified before implementation starts. And if they will not be seen, chances are even bigger that you will hit upon these holes when starting to implement the code.
• Make use of my 4-steps recipe (create, embed, write, and construct) for the conception of the test code. Let the ATDD.TestScriptor module and/or extension make this work even more efficient.
• Get the test(s) run with every...

Making the test tool, and some more, your friend

In Chapter 4, The Test Tools, Standard Tests, and Standard Test Libraries, 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 deliberately cause a verification error. Next to VS Code, your coding tool, and debugger, the test tool is one of your best friends. Keep it running while you develop, and do not wait till the code is ready; verify each atomic change by running the tests, as mentioned previously. The goal is to make automated testing part of development.

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...

Maintaining your test code

Like application code, test code is also code, so handle it as application code should be handled. This means:

• Test code should be secured by means of a source code management tool, providing you a history of changes and an easy way to revert to any previous state.
• Test code will most likely need to be updated with any new customer wish, as this will result in a change of the behavior of your solution.
• Test code most probably needs to be debugged, whether you like it or not, as any coding done by a developer potentially inserts new bugs, in both the application and the test code.
• Test code should be reviewed to ensure that, like application code, it meets the coding standards.
• And of course, test code should be stored with the application code to assure they're closely tied and in sync.

Next to this, when allowing other parties to extend your extension, empower them by providing access to your test code, like Microsoft...

Organizing your extensions

Starting with a new project, like we did with the LookupValue extension, I tend to have both the application and the test code in one VS Code folder just for one reason: practicality. This way, I only have to deploy one extension when verifying my work after an addition or change in either application or test code – or both, although TDD teaches us to do one or the other. This helps me to get my work done more efficiently.

Once the code is ready, however, we need to make sure that the application and test code end up in separate extensions – but still in the same repo – with the logical consequence that the test app will have a dependency on the application app. This way, we prevent tests from ending up, and possibly getting run, in a production environment. For this very reason, standard CRONUS does not contain the standard test codeunits – and test helper libraries.

Sure, if test codeunits are run within the test isolation...

Integrating with the daily build system

Software development is about building applications that link and automate business processes. Modern software development should do the same with respect 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 to show the validity of the rebuild software, triggered by a completed build, or being part of that build
• Deploying a build approved by the automated tests automatically on demand, on a scheduled time, or on every new occurrence
• Collecting all the results and statuses of the foregoing processes on a dashboard to inform the stakeholders about the health of the software

Contemporary development tools, such as Microsoft Azure DevOps, enable you to achieve this, to integrate your test automation effort with a build process. Figure 9.13 shows...

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. Be aware that test code is also code, so maintain it as you maintain your application code. Organize your final application app, and its accompanying test app, in such a way that tests cannot be run in a production environment accidentally. And last but not least, automate parts of your development processes with automated builds that include running your tests.

In the next chapter, Chapter 10, Getting Business Central Standard Tests Working on Your Code, we will have a closer look at the tests provided by Microsoft and how we could also integrate this humongous collateral of standard tests.