Head in the Cloud

Test Driven Development (TDD) is a development/design approach in which we write our tests first, then implement the code to make these tests pass. What TDD is Not These initial tests we write are not unit tests in the traditional sense. I'll repeat that: TDD tests are not unit tests. What are they then? TDD tests are specification tests. They are an example of how to use the thing being built. Sure, we'll use a "unit testing" framework to build, them, but don't get hung up on terminology. The idea is, we're testing, and showing an example of, the API, not testing the logic of an individual piece of the several pieces that make up the implementation of that API.  Let's look at a simple example: Let's take a feature and a scenario: Vendor Lookup Feature: Users can search for Vendors in the system. Scenario: Search by a company name beginning with the search term. Given the following vendors | CompanyName | | Acme Supply | When the company name...

Most of the time, your solution will have more than one project and a test unit project for each of those. Azure DevOps only, as of this writing, only allows you to update a single code coverage summary. If you upload more than one, each overwrites the next and only the last one remains. To accomplish this, we can use the merge functionality in Coverlet . I use the MSBuild extension, because it is better suited for CI pipelines. In your test project XML, add the package... <PackageReference Include="coverlet.msbuild" Version="2.7.0">     <PrivateAssets>all</PrivateAssets>     <IncludeAssets>runtime; build; native; contentfiles; analyzers</IncludeAssets> </PackageReference> Then, in your dotnet test command or msbuild command, tell it to use Coverlet and to merge results. If you're using Azure DevOps, your test task looks this... (line wrapped for read ability in the article) - task: DotNetCoreCLI@2 displayName: Test i...