Related to my previous blog post: Azure DevOps – D365 CE Tests: Part 1 – Setting up the pipeline
Introduction
Even if you are a sole developer in a project, you should remember that there’s a way to include other team members in your work! Make them interact with your integration test by teaching them how they can run your integration tests on their own. Show them a beautiful 🤩 visualisation of the test results and how to easily create bug issues from the failed test cases.
The Problem
Most of the time, your tests are only available to you. And is only interesting to you. Even if your architect, project manager, etc are aware of your code-tests. It doesn’t result in the same wow-factor as someone who, for example, presents a beautiful scrum board or an awesome burndown chart 📉 that the customer can see at any time. The ability to visually perceive and engage with an object reinforces its authenticity. It presents a different sense of value.
How I Solved It
Here’s how you can make tests a lot more interesting for your team! Not only is it interesting in terms of being able to see and run test, but to actually catch potential collisions between code implementation and process configurations!
In the previous post, I showed how you can set up a pipeline for your test project. If you check ‘Publish test results and code coverage’ it’ll publish the results to ‘Test Plans’.
To see the actual test results, double-click on a test run from the list (see screenshot above)
If you navigate to ‘Test Results’ tab, you’ll see the result of each test case.
Double clicking on one of the test results will navigate you to a page where you can see more details of the test result. From here, you have the option to create a bug/issue on the test result case.
As you can see, your team members can finally interact with your integration tests and see the beautiful results. Through these integration tests, they can see if their implementation of Business Rules, Workflows, Low-Code Plugins, Power Automate, etc (sadly not JavaScript) has affected any other processes, assuming your integration tests has covered the some parts of the affected area. This also applies to your customer if they implement configurations/customisations. And this will make it a lot easier to catch errors early on.
You can also configure so that integration tests only run for a specific entity or a certain scenario. It depends on how you’ve configured your test project. I’ll show more technical examples in part 3 of the series.
There’s probably a lot more you can do in Test Plans in relation to the integration test pipeline, but this is all I know as of now. I have still a lot more to learn and explore!
Final note to part 2, and an important one too, this type of integration testing is not suited for all projects. It depends on the budget, project size and available resources. It may be time consuming, and it will certainly add an extra layer of administration (technical side). However, in the long run I believe it will do more good than harm. Especially if the system continues to grow.
Happy testing!
Van Carl Nguyen 