Chapter 11: How to Construct Complex Scenarios

Whereas the examples in Section 3, Designing and Building Automated Test for Microsoft Dynamics 365 Business Central, covered the main, one-fold principles of an automated test using the ATDD format, this chapter shows you how to go about complex scenarios.

To achieve your goals as an end-user in Dynamics 365 Business Central, being the ERP package it is, you often end up exercising a substantial chain of consecutive actions. Say you need to test applying a payment to a posted invoice. In order to run this process, a number of related things need to happen first. You have to create a customer, create an item, create and post the invoice, and create and post the payment. And eventually, verify all relevant results.

How do you go about constructing a suite of tests for that? How to create reusable parts? And how to make use of already existing helper functions in the Microsoft test libraries?

In this chapter, we will get answers...

Technical requirements

Like in previous chapters, we will refer to the LookupValue extension. Its code is to be found on GitHub: https://github.com/PacktPublishing/Automated-Testing-in-Microsoft-Dynamics-365-Business-Central-Second-Edition. In this chapter, we will continue on the code from Chapter 9, How to Integrate Test Automation in Daily Development Practice, and not include our findings from Chapter 10, Getting Business Central Standard Tests Working on Your Code: https://github.com/PacktPublishing/Automated-Testing-in-Microsoft-Dynamics-365-Business-Central-Second-Edition/tree/main/Chapter 09 (LookupValue Extension).

The final code of this chapter can be found in https://github.com/PacktPublishing/Automated-Testing-in-Microsoft-Dynamics-365-Business-Central-Second-Edition/tree/main/Chapter 11 (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...

What makes a scenario complex?

Complexity is a relative concept. It highly correlates with the perspective and expertise of the person or team facing it. Nevertheless, there are generic, common facets that can introduce complexity. In the context of test automation, complexity can be found in the following factors:

• Data setup
• Verification
• End to end code execution path
• Dependencies on other systems

Recognizing each of these factors in general terms – and, of course, even more in specific circumstances – helps you a lot in reducing the complexity. Or should I say: handling the complexity? It will support you to deconstruct a complex issue into a collection of simpler things. Even though this collection may still be overwhelming as a whole, it enables you to solve it step-by-step, a recurring approach in this book. An approach that allows you to take small steps and gives you a great chance to design reusable, readable, and minimalistic code.

...

Composing complex scenarios

Now that we have outlined what can make a scenario complex, it will be very practical to describe how we could compose complex scenarios enabling us to handle them efficiently and effectively. One after the other, the following are the hurdles to take to help you to get there:

1. Before a feature is being implemented, a test plan should be in place, detailed out in a test design, and reviewed by the team, as was discussed in Chapter 5, Test Plan and Test Design. Well-thought-out ATDD definitions will save a lot of work downstream.
2. Describe the data setup – the ATDD GIVEN parts – for your complex scenario, efficiently and effectively making use of a common language (see Chapter 5).

   Remove unneeded details and unveil missed details by team review.

   In this, make a clear split between this part – data setup – and the next – exercise. Determine what are the preparatory, data setup, steps needed to get the code under test...

Creating reusable parts

One of the reasons software development and automation has such a prominent place in today's world is its repeatability. Recurring tasks can be executed in exactly the same way repeatedly. But it's not only this kind of repeatability that's responsible for automation's prominent place. It's also the ability to create reusable parts. Now, you might recall that in practicing TDD you, at first, do not focus on generalization, that is, creating reusable parts, but let this emerge as part of the refactoring. And that is fully true. So, with TDD we first focus on getting the test(s) implemented. This, however, does not prohibit us from designing our test in such a way that we reveal and make use of common ground as discussed in Finding common ground – steps 1, 2, 3, and 4.

Test example 10 – how to construct an extensive scenario

To give an illustration of the above, we elaborate on another part of our customer wish.

Note

In this example, we focus on the specifics discussed above, not on the whole implementation – test and app code – of the scenarios. As such, our discussion will not follow the order of the TDD red-green-refactor mantra and will only include code if it is relevant for the context. The completed test and app code can be found in the GitHub repo.

Customer wish

In the business logic description of our customer wish it is mentioned that:

When creating a warehouse shipment from a sales order, the Lookup Value Code field should be inherited from the Sales Header to the Warehouse Shipment Line.

This is expressed in the following two scenarios:

[FEATURE] LookupValue Warehouse Shipment
[SCENARIO #0030] Create warehouse shipment from sales order with
         ...

Summary

In this chapter, you learned what things can make a scenario complex and how to go about handling them efficiently and effectively, finding common ground, deconstructing it, and using flowcharts, code coverage, and reusable parts, the latter being either standard helper functions or ones you create yourself.

In the next chapter, Chapter 12, Writing Testable Code, we will discuss how to write code that is better and more testable with test automation.