Test Driven Development (TDD) Simplified

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 begins with the term "Acme"
Then then 1 record should be returned: "Acme Supply".

We know we need to build a component with an API that allows us to search for a vendor whose company name starts with the term provided. What should this API look like? How do we want developers to interact with this API? What type should it return: the domain entity? a summarized projection? What collection type should it return: an array? a List? an observable stream? Do we want an interface or just a class implementation? Let's write a test to answer those questions.
Simple enough. It certainly tests our feature scenario and gives us a feel for now a developer will interact with this API. It also raises some discussion points (and is why I like pair or mob programming):  Here we chose to return the entire vendor entity. Do we really want that? Should it be a summarized projection--e.g., just the Id, CompanyName, and a PhoneNumber? Should we limit the number of results--what happens if this returns 1,000's of vendors? If we decide to page the results, how do we convey that to the developer and ultimately the user? Given this will ultimately involve an IO operation of some kind, should the API be non-blocking (async)?

We can make some design decisions as a team and iterate over the test:
There. We have a pretty good initial API spec...er...TDD test.  Now we can implement our component. When we do, additional things will come up that will require us to come back and write more tests to cover more cases for this scenario:
  • What do we want to happen if the search term is null or empty?
  • Should the page size be constrained, and to what? What happens when a value outside that range is provided?
  • What if no vendors match the criteria?

These answers will require collaboration with the customer.

The tests for these will feel a bit more like unit tests, as we are testing specific code paths within our find method, but we're still really testing the specification: a null search term should throw an AgrumentNullException.

Taking it a step further

In this example I kept it simple.  We just looked at it from the service component interface. The "API" example being spec'd out and tested can just as easily have been a REST-ful API or GraphQL or gRPC service. Or the test as we wrote it could be against a client library that makes that backend call, providing a more integration-style test where we are testing the protocol/anti-corruption layer in our tests as well.

The goal of these tests, like any test, it to give us confidence that our code works without any known bugs and the confidence to make changes--e.g., optimizations--to the code and know we didn't break anything. 

A side note on agile and rapid feedback

As you can see, TDD allows us to raise questions about design early on. It also fosters a much more agile culture. The initial implementation of the happy path for our customer lookup could easily be built and demo-able in a running (*cough* production) environment in just a couple hours so we can get that feedback we need to answer the additional questions.

One of the best customers/Product Owners I ever worked with said: "I don't know what it needs to look/work until you show me." Her approach meant we collaborated constantly. We would show her the work several times a day and get that rapid feedback. The result was high a higher quality product, offering only value and no waste, no known bugs, and a significantly shorter time-to-market.

Comments

Post a Comment

Popular posts from this blog

Using NHibernate in Asp.Net Core

Starting with version 5.1, NHibernate now supports .Net Core and .Netstandard as well as the full framework. Let’s take a quick look at how to set it up in an ASP.Net Core 2.x/3.x application. Configuration As of this writing, NHibernate doesn’t support the configuration system within Asp.Net Core based on Microsoft.Extensions.Configuration. The good news is, you don’t have to use a  hibernate.cfg.xml  file or the   section in app.config. You can add the properies manually, and pull the values from Asp.Net Core’s configuration, taking advantage of all the goodies that come with it. This opens up a world of configuration deployment possibilities. var config = new Configuration (); IDictionary < string , string > properties = new Dictionary < string , string > { { "connection.connection_string" , Configuration . GetConnectionString ( "Default" ) }, { "dialect" , "NHibernate.Dialect.SQLiteDialect" }, ...
Read more

Adding New Microsoft Extensions to Legacy WCF and ASMX Web Services

I was asked by several people recently: Can I use dependency injection with my legacy WCF and ASMX web services? Microsoft has some new stuff they released with core–specifically, a new configuration system, caching, and logging providers. Can I use them in my legacy WCF and ASMX web services? The answer to both is yes you can! In fact, I recommend it! To illustrate this, we’ll take a look at taking a sample application that has a WCF service and a ASMX service and we’ll: Add dependency injection using Ninject. Add the new Configuration provider from the new  Microsoft.Extensions.Configuration  packages. Add caching functionality using Microsoft’s new  Microsoft.Extensions.Caching  packages. Use the new logging providers from  Microsoft.Extensions.Logging  packages. Dependency Injection We use Ninject, but you can just as easily use AutoFac or SimpleInjector as they also have packaged integrations for WCF. You can use other containers, bu...
Read more

Code Coverage for Multiple Projects in a Single Build using Dotnet Test and Coverlet

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...
Read more