Chapter 13: Testing Incoming and Outgoing Calls

In the connected world that we are in, chances are big that your extension enables external systems to call into Business Central by providing one or more APIs and/or makes its own outgoing calls to external services. Both incoming and outgoing calls are two mirrored sides of the same medal, where a so-called client process is calling into a service. With an incoming call, it's our service being called upon by an external client, whereas with an outgoing call, it's an external service being called upon by our client process. Testing the one – handling an incoming call – is about verifying the validity of the service, while testing the other – handling an outgoing call – is about verifying the validity of the client process. To test the incoming call, we need to mimic the calling client; to test the outgoing call, we need to mimic the service being called. In both cases, our challenge is how to do...

Technical requirements

Like in the previous chapter, 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 the first test example of this chapter, Test example 12 – testing incoming calls: Lookup Value API, we will continue on the application code from Chapter 12, Writing Testable Code: https://github.com/PacktPublishing/Automated-Testing-in-Microsoft-Dynamics-365-Business-Central-Second-Edition/tree/main/Chapter 12 (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 13 (LookupValue Extension) for Test example 12 – testing incoming calls: Lookup Value API and https://github.com/PacktPublishing/Automated-Testing-in-Microsoft-Dynamics-365-Business-Central-Second-Edition/tree/main/Chapter...

Testing incoming calls

Connecting from an external system to Business Central has been enabled in Business Central by so-called Web Services and APIs. Where web service, as such, is a very generic term, entailing both Web Services and APIs, Business Central has used it to name their very first implementation of web services after it. Web Services were introduced in Dynamics NAV 2009 and are still available in Business Central. They can either be SOAP- or OData-based. Given a number of limitations of Web Services, however, Microsoft has put in place a new version of web services, which are called APIs and are REST-compliant, a.k.a. RESTful. In his Areopa webinar Working with APIs, Arend-Jan Kauffmann gives a nice introduction to APIs starting with a comparison between Business Central's Web Services and APIs. If APIs are new to you, you can learn more about it with the recording of the aforementioned webinar available at: https://www.youtube.com/watch?v=-BLNMTf7r5k.

Note

...

Testing outgoing calls

In everyday practice, both incoming and outgoing calls happen between two separate, independent systems. This makes testing of incoming and outgoing calls a challenge with respect to controlling the flow of the tests. As shown in the previous section, Testing incoming calls, with incoming calls we can quasi switch between client-side and server-side while actually running our tests on one system. With outgoing calls, however, this is not possible as our application code – the client – is most likely calling upon an external system – the server – that we do not and cannot control and/or we do not want to interact with for whatever reason in our test context. In Chapter 12, Writing Testable Code, handling the interaction with an external system was mentioned as an example of why we should be writing testable code. Testable code should allow us to mimic the interaction and test the behavior of our application code given a controllable...

Test example 12 – testing incoming calls: Lookup Value API

With this example, you learn how to test getting (using GET), deleting (using DELETE), modifying (using PATCH), and creating (using POST) data through an API.

Note

In this example, we focus on the structure and code of the automated tests that test an API, not on the flow of getting from a customer wish into test and application coding and also not on doing it the TDD way.

Application code

The object for our tests is a new page called Lookup Values APIV1 (50090) with PageType set to API and SourceTable pointing to our Lookup Value table. This API contains three columns:

• id based on SystemId field
• number based on the Code field
• displayName based on the Description field

The full object can be seen in the GitHub repo: https://github.com/PacktPublishing/Automated-Testing-in-Microsoft-Dynamics-365-Business-Central-Second-Edition/blob/main/Chapter 13 (LookupValue Extension)/src/page/LookupValuesAPIV1...

Test example 13 – VAT Registration No. validation

In this example, we are going to show how the standard VAT registration number validation feature in Business Central could be made testable, enabling us to mimic the validation service. For your convenience, we have duplicated Figure 13.2 here, showing you the basic flow of the VAT registration number validation:

Figure 13.7 – VAT Registration No. validation flow with a test double server

As we are not able to modify the code behind this standard feature, and as the code does not provide the right means to hook into it, we will build a standalone feature that imitates the process, as discussed in Replacing a server with a test double – dependency injection section. This standalone feature allows us to demonstrate how DI could help make an outgoing call testable.

Note

As in the previous example, we will again focus on the structure and code of the automated tests and not on the flow...

Summary

In this chapter, you learned first how to test incoming calls, that is, how to test your own APIs, and secondly, how to test outgoing calls, that is, how to enable the usage of test doubles by means of dependency injection (DI) enabling in your code.

With this chapter, the book has come to an end. But your journey into test automation might have just started. To me, every time it's still fun to pick up. It enables me to go astray in my application code, finding the results of my test pulling me back. It allows me to refactor my code at any time. It also enables me to reflect on the quality of the code more easily because it can be changed and instantly checked. I could go on with my praising and more or less redo the first chapter of this book but I won't, as it is time to conclude for now. I hope you enjoyed reading and practicing with me as much as I did while writing.