Addendum #03 – Simplifying API testing using basic authentication

Time for another addendum to my book: simplifying API testing.

In the first part of Chapter 13, Testing Incoming and Outgoing Calls, I discuss how you can go about testing incoming calls, i.e. calls to your APIs. In this I followed the approach by MS in testing their APIs:

1. Set up your Business Central environment to use Windows authentication
2. Remove all user and user-related data from the database (see this script)
3. Deploy your extension(s) with your application and test code
4. Run the tests with standard test runner Test Runner - Isol. Disabled (130451) as client and server processes run in different sessions

What was missing?

The major drawback in this approach is that the NST needs to be setup to use Windows authentications. This throws up a challenge when running tests in a pipeline as most probably the various parts of the pipeline are not run/triggered in your domain. UserPassword authentication would make it all so much easier.

Triggered by my Dutch Dynamics Community presentation, and later my Areopa webinar, Automated testing of your Business Central API, Arend-Jan Kauffmann – who else – suggested to use the following trick allowing the usage of basic authentication. In this we are assuming we’re using a docker container.

1. When building the docker container for testing the APIs the user and password are known
2. Adjust the script in such a way that it:
   • adds an extension which introduces a table in BC – let’s call it Test Setup – with a field in which the password can be stored
   • populates that field with the password
3. Design your API tests to make use of this password (combined with the user)

I recorded this suggestion as an issue, i.e. Issue 16 Testing APIs: using basic authentication, on the GitHub of my book to enable to work on it in due time. The unexpected effect, however, was that it was picked up be some else.

How was it fixed?

The same day I created the issue Arthur van de Vondervoort added to it:

Our development and our Azure DevOps pipelines environments are all setup-ed with Username/Password.

The idea is to create a small extension to have a eventsubscriber on the OnBeforeGetResponse and add BasicAuthentication to the API-call. With this maybe the standard tests of Microsoft would also be able to execute?

For now waiting for the event request here: microsoft/ALAppExtensions#15756

It stayed silent for a time, not in the least as the issue still not had my priority. Apparently Arthur had not been sitting still, as two weeks ago he returned with a very pleasant message:

@lvanvugt: Good news, I have testing APIs working using basic authentication!

And continued with all details needed to get it indeed working. I only needed to find some time to get working on and get all the nuts-and-bolts set right, including the pipelines I had setup on the Azure DevOps project for the book.

I adopted into the GitHub repo as follows:

1. Created a new branch called BC20 as, with the new event publisher OnBeforeGetResponse this will only work on BC20.1 and next
2. Adopted the three new codeunits that Arthur suggests:
   • GraphMgtEvents.Codeunit.al
     Contains subscriber to OnAfterInitializeWebRequestWithURL assures that the users credentials are added to the http call
   • InstallWSKeysforUsers.Codeunit.al
     Adds to each users in the database a Web Services Access Key
   • InstallAPITestSuite.Codeunit.al
     Sets up a new test suite API to contain our test codeunit(s) with our API tests and links a test runner to it, i.e. Test Runner - Isol. Disabled (130451) that disables test isolation
3. Created a new pipeline for Chapter 13 to run the tests and also a BC20 specific pipeline for the final app/test app setup to also include the API tests
   The challenge in the latter was to have both to original tests running with test isolation and the added API tests without isolation; you can learn from my notes on GitHub Issue 16 Testing APIs: using basic authentication and the .yml file on what this all entailed.

A BIG thanx …

… to Arthur for making this possible and, of course, also one to AJ.