TDD an IoC container - part 4 - Tools

This post series looks into how I apply TDD in order to have confidence in what is developed.

In this post I wanted to look a little into the tools used to continuously run the tests, which ensured that we did not break the contract while we have been refactoring the code.

catch-up

At this point we have

confirmed how the tests should drive the code (at the moment i would say this is mostly followed)
since the last post we have added support for IEnumberable, Lazy, more support for Threading.
the internal code may not be the cleanest (we are refactoring constantly now, improving existing functionality and adding new features)
given the project a name: Bonsai

Overview

We are coding in .NET Core (Standard), and we have started this project with a number of tests, which we have tried to use as the requirements.

With regards to tools there are a number of tools at our disposal, and we will look at the local development tools as well as the continuos integration tools.

Testing Tools

Mspec - Test Framework which has been used
Mspec dotnet adaptor - allows tests to be run with the dotnet cli.

Local development

I tried 2 different set of tools during the development of this library

VS Code - FREE option (and it works well)

Tools

VS Code => editor
Coverage Gutters => shows the lines of code which have been covered
Coverlet - dotnet Cli plugin which runs code coverage
Test Explorer - shows the runable tests - note this was able to run the tests, however the experience is not 100%. (at the time of writing)

Code supports .NET core really well, including some code refactoring. The best part to this setup was a small plugin which enabled code coverage to be seen against each line of code.

In this setup we take advantage of the dotnet test adaptor (which runs MSpec) and use its watch command.

dotnet watch --project ./src/Bonsai.Tests test /p:CollectCoverage=true /p:CoverletOutputFormat=lcov /p:CoverletOutput=./lcov.info

Now when we save a file, the tests are rerun and we get automatically updated in VS Code to what has been covered.

Rider

Tools

Rider => IDE (compile, test runner and code coverage)
MSpec plugin => provides great integration

This experience was fully integrated, and offered the best experience with MSpec, allowing us to select a individual test as well as rerun all tests with code coverage on file saves.

Either tool I fund to be a great place to code.

Continuous Integrations

here we have several tools which try to ensure that quality is met/retained, and all of them run silently in the background (to enable a smooth process)

Github - Source Control, somewhere to store the code, where others can hopefully contribute.
AppVeyor - Build service
CodeCov - Code Coverage reports
Codacy - Code quality reports
Nuget - Package manager

some notes on the above tools

##Testing

Code Coverage is supplied by the same library as before Coverlet, however we need to configure it to produce reports in the OpenCover format in-order for CodeCov to process.

In addition AppVeyor supports a set of known result formats, luckly dotnet test support a logger called trx, which can be uploaded to the mstest end point

The following shows how these 2 reports are generated and then uploaded to the correct service endpoint.

dotnet test --logger trx --results-directory ./results /p:CollectCoverage=true /p:CoverletOutputFormat=opencover /p:Threshold=70 ./Bonsai.Tests

cd Bonsai.Tests
Invoke-WebRequest -Uri 'https://codecov.io/bash' -OutFile codecov.sh
bash codecov.sh -f "coverage.opencover.xml"


$wc = New-Object 'System.Net.WebClient'
$results = Resolve-Path .\results\*.trx
$results = $results[0]
Write-Host $results
$wc.UploadFile("https://ci.appveyor.com/api/testresults/mstest/$($env:APPVEYOR_JOB_ID)", ($results))

The above took a little of digging around.

Quality

I have focused mostly on correctness (passing tests) and then on speed (benchmarks), however I do care about quality, thus I have included CodeCov within the tools.

at this point we only receive a ‘B’, however the report includes a detailed output of where in the code the changes need to be made.

at the moment I do not agree with a B score, I was hoping it to be more critical over the classes sizes and responsibilities. something to indicate if SRP may be broken. I will look more into this, to ensure that im not missing something.

Wrap up

For an open source project there are so many tools we can get our hands on to help with the continuous integration of new changes.

All of them offer great insight, of which we can act on in due course.

Dave R.