Integrate automated testing in your GitHub CI pipeline (.NET API)

Once you have written down automated tests for your .NET API next step is to run them inside your CI pipeline.

---

The goal

• Build a CI pipeline to run our test suite.

• Show the test run/coverage results inside the pull request.

• Create a reusable base for future projects.

We are going to use the CardGameStore.API we have developed as part of the newsletter so far (grab the code at the bottom of post).

The tests that we will run on every pull requests will be the following:

• Unit

• Integration / Subcutaneous

• Contract

Once tests are completed we will aggregate the results and update the pull request.

---

The project structure

This here is the structure of the project we have built so far:

---

Creating the first GitHub action

Small disclaimer: The following pipeline is a sum up of different pipelines and tools I’ve seen/used over the years.

1. To get started we need to create a blank workflow file at .github/workflows/build.yaml . This is the default location for your GitHub workflows.

2. Next we need to define when do we want to run the pipeline. Here is my setup:

   

3. Now we need to define the jobs that we want to run. In our case it’s going to be a simple “Build and Test” job with multiple steps.

   

4. The first step of the job will be mostly a fetch and setup.

   

5. I prefer running one type of automated tests at a time, so I split the runs across multiple steps. (Feel free to zoom in the image :) )

   

6. Now comes the fun part where we are going to combine the reports. And store the results into the coveragereport directory.

   

This step requires some explanation.

First: we are going to use a free tool called Report Generator. This tool will convert the reports that are generated by coverlet (that is already installed as NuGet package into every test project)

Second: there are a bunch of report types that it can generate. I’m interested in the HtmlInline and Cobertura. We will return to the MarkDownSummaryGithub in a bit.

Third: verbosity level of the logs message is left to information for easier debugging if sh*t hits the fan.

7. Once the report has been generated we need to upload it as artifact.

   

   Once the workflow has been run you will see this in the summary of the run:

   

   What we are interested in is the CoverageReport archive which when downloaded has a report similar to this one (feel free to navigate to the site to view the report it’s 100% better than a screenshot.)

   — A neat feature there is the ability to see where you should increase the coverage.

8. Next step is to add a comment to the Pull request with the code coverage report. To do that we can either:

   

   Use this approach with would add a simple easy to read/understand comment, like this one:

   

   Or go the complex way and use the following step:

   

   Which would give us a big report as a comment to the PR.

   

   I for one prefer the smaller one, since I can always view the full report from the artifacts if I need to.

9. Running these 2 steps will generate a message in the pull request which would show us the test run results:

   

   

   PS: also it will update the summary of the run with the exact same text as you see in the comment, and in case there were tests that failed it will include the failed assertion text and the location in the code. (which is really helpful)

---

End result & Shot outs

We have a pipeline that runs our automated tests, aggregates the results and updates the pull request with the respective information. All this done relatively easy.

At the end I want to do a shot out to the authors of the custom actions and tools that I have used in this pipeline. Feel free to reach out and maybe thank these guys for their effort and dedication: irongut, marocchino, Enrico Minack, and special thx for Daniel Palme with his awesome report generator tool.

---

Next steps

If you liked this kind of content/tutorial I will be really grateful if you cloud share it among your colleagues and friends in order to grow the newsletter further.

Heads up:

1. Subscribe to the YouTube channel where I cover a wide array of .NET related topics.

2. Earlier this year I release an entire course around the topic of building a Modular Monolith system that you can find clicking here : Microservices Ready Architecture

3. Become a Patreon and get access to the source code presented in the newsletters and YouTube channel.

And with that cya next time :-)