There are a few different approaches to testing in the spectrum between simple unit tests and complete E2E tests. If I had to choose one approach to prioritize I would pick integration tests.

The key reasons are:

• Tests a flow of multiple functions, in contrast with unit tests where only a single function is tested
• Self contained i.e. the test has no external dependencies on a deployed environment etc.
• Makes logical sense to test a complete function in a REST api, a single Lambda in AWS or an Azure function

The problem

In my case the goal was to setup a test suite for a .NET web api. I quickly realized that the naive way to explicitly instantiate every controller plus all dependencies would lead to lots of repeated boilerplate code in order to setup a test case. I also wanted to make use of the existing DI configuration.
So how to create a generic setup where new test cases is a breeze to create? 🤔

One of the projects we work with at Devies is related to the dental domain. In that project we use the dental notation (ISO 3950) to refer to teeth. Every tooth have an unique identifier that consist of two characters. The first character represent a quadrant (one of four areas in the mouth). The second character is an identifier that refers to one of the eight teeth in that area.

Early on in the project we represented the tooth identifier using a string, for example "42" (4 is the quadrant, 2 is the identifier). As the project grew we stared to use this tooth identifier in many different places in the project. Since we use a raw string, we had to make sure the tooth identifier was properly validated at every place where it was used. Additionally, it was unclear what the tooth identifier (string) represented, and it affected the readability of our code.