Which testing types you choose to implement depends on your requirements. Some form of unit testing is most often performed by the person who is writing the code. Once unit testing is completed, a TDD model can call out any new issues that have been introduced by the updates. In every case you should enforce this type of testing, for both manual and automated testing scenarios. Integration and functional testing can overlap somewhat, in that they both should take place in an environment that is not on a developer workstation or workspace. Instead, all changes should be installed into a completely different environment where all the code being released for a specific version is brought together. Integration testing confirms that the technical components work together, and functional testing confirms that the results of the testing still meet the business requirements. Performance testing makes sure there is no degradation of execution speeds. Lastly, regression testing checks for newly introduced bugs and for bugs that were fixed in a previous version being overwritten by a new change. This can happen if the developer took the wrong, older version of the pipeline from the source code repository that contains an old bug. The old bug was fixed in a newer version of the pipeline but will be overwritten when the new code changes are applied to the production branch.

Tools that can be used for automating testing include Azure DevOps, NUnit, and Azure PowerShell/CLI. Azure DevOps is by far the most sophisticated tool for managing automated test plans and for achieving CI/CD. Table 6.6 provided the different components of Azure DevOps, and Figure 6.67 showed a release workflow that included Azure Test Plans. Creating an Azure DevOps organization and projects requires many configurations that typically only Subscription administrators have access to. That (and the security‐related complexities) is the reason you will only see the details of how Azure Test Plans looks instead of completing an exercise. Azure DevOps is located at a URL similar to the following:

https://dev.azure.com/<organizationName>/<projectName>

After replacing the organizationName and projectName with your unique values, you create an Azure test plan by clicking the + New Test Plan button on the Test Plans page, as shown in Figure 9.27.

FIGURE 9.27 Azure DevOps Azure Test Plans New Test Plan

Once the test plan is created, you are offered the option to create test cases. In this context there are three test cases, one for each pipeline activity within the TransformSessionFrequencyToMedian pipeline. Each test case contains two steps. The test case resembles Figure 9.28.

When you select the Execute tab, the test cases are rendered to the page. Each step within the test cases is performed manually and their status recorded, as shown in Figure 9.29.

When a step within the test case fails, the outcome is set to a status of Failed and a textbox explains the reason. There is also a button to create a work item on the Azure DevOps Board so that the issue is documented and a developer or data engineer can look into it. The Chart tab enables you to create a visualization of the overall test plan status. This is very helpful for larger enterprise projects that have many team members testing many test cases.

If the endpoints of your Azure Synapse Analytics endpoints are not blocked by firewall rules or private endpoints, you can use an SDK or Azure PowerShell/CLI to test your pipelines. For example, you can use NUnit, a tool for testing code written within the Visual Studio IDE (https://docs.nunit.org). You can then write the code to trigger the pipeline, check the status of the pipeline, and check the storage account container for the expected results. Combining the code that performs the test with the NUnit framework can help you execute, monitor, and react to test plans from within Visual Studio. The endpoints called from the SDK are the same as those called using Azure PowerShell or Azure CLI. Therefore, the concept of their implementation is the same, in that you would call the ARM API from the related cmdlet to trigger a pipeline, check the status, and then check the output in the storage container for the expected results. This approach is a bit more manual; however, the entire test plan, like the one you create with an SDK, can be executed by a single press of the Enter key.

FIGURE 9.28 Azure DevOps Azure Test Plans New Test Cases

FIGURE 9.29 Azure DevOps Azure Test Plans Execute Test Cases