Search for a command to run...
My name is Michael Lehmann. I'm a developer, architect, technical team lead and occasional speaker. I work for Zühlke Engineering AG as a Lead Software Architect aiming to help my customers and team mates to design and develop software. I specialised in developing distributed systems with micro-service architectures and modern web technologies.
No comments yet. Be the first to comment.
If you read my blog regularly you may have noticed that I recently introduced pagination to my article list. In order of that, I would like to explain how I implemented that with the tech stack of my blog - NextJS and MongoDB. Pagination is one of th...
A good friend of mine once told me about a conference talk that was about so-called task-based UIs. I considered this architecture style for an application in a private bank which was responsible for checking the suitability for finance instrument tr...
I recently implemented a small hint showing the reading time of an article in my blog. This is a functionality used quite much when reading some technical articles written by the developer community. It helps me to decide whether I have the time to r...
In larger projects, the cooperation of several teams and long-term maintenance is always an issue. The architecture must be defined in such a way that such aspects are possible. This is often implemented with a certain degree of modularization. This ...
On this page
15 years ago, C# did not have a large variety of unit test frameworks and supporting libraries.
That has changed in the meantime. The community has grown considerably and so has the range of libraries and tools that can be used for unit tests. While Asp.Net Core is the absolute standard for a REST API, there is hardly any software project that uses the same setup for unit tests.
The choice of a unit test project setup is also often very much driven by developer preference and opinions. I have even seen developers insisting on a specific unit test framework at the customer site.
Even though no project has ever failed with the selection of the unit test framework, it does have an impact on the productivity, maintainability, and readability of the code. And of course, I also have my preferences, which I would like to describe here.
Let's first discuss the unit test framework we use.
I started using XUnit during the early days of .Net Core. At that time there was no framework besides XUnit that ran on .Net Core. The MSTest framework was ported later, but I like the ability of XUnit to write simple data-driven tests. Also, XUnit provides an easy way to share context between tests with the fixtures. This also makes it easy to write database and integration tests. There would also be NUnit in the field, but I never like NUnit, since it is quite heavyweight compared to XUnit.
Mocking is also an important aspect of unit testing. I have used NSubstitute and Moq in the past. I like Moq a bit more since it is a bit more powerful about mocking protected members and most of the projects I joined used Moq, so it is quite popular.
But I don't use Moq alone, I always use it in combination with Moq.AutoMocker. AutoMocker creates an instance of a target class and automatically mocks all its dependencies. When I introduce a new constructor parameter in a service I want only touch the tests that test some specific aspects of a new dependency and not all tests. AutoMocker helps with this approach since it adds the ability to create an instance of a class and automatically mocks all dependencies.
Example from the Moq.AutoMocker documentation:
var mocker = new AutoMocker();
var car = mocker.CreateInstance<Car>();
car.DriveTrain.ShouldNotBeNull();
car.DriveTrain.ShouldImplement<IDriveTrain>();
Mock<IDriveTrain> mock = Mock.Get(car.DriveTrain);
In a project with large entities, it is a big effort to provide the test data. In various projects we implemented so-called entity generators. Entity generators are simple and configurable classes to create entity instances.
public class AgendaItemBuilder : EntityBuilder<AgendaItem>
{
private string _title;
public AgendaItemBuilder WithTitle(string title)
{
_title = title;
return this;
}
protected override async Task<AgendaItem> EnhanceEntityAsync(AgendaItem entity)
{
entity.Title = string.IsNullOrEmpty(_title) ? $"Title of {nameof(AgendaItem)} {unique}" : _title;
return await Task.FromResult(entity);
}
}
This can be used for following:
var builder = new AgendaItemBuilder()
.WithTitle("My Title");
var entity = builder.Build();
The advantage of those builders is, that you have a shared class preparing the test data for a specific entity. But it is still a big effort to write and maintain them. Another drawback is that the test data contains static data which are always the same until it is specified otherwise.
A while ago I came across a library called Bogus. Bogus uses a random generator to generate test data. The test data is context-specific, e.g. addresses, names, phone numbers, etc. Bogus has a huge list of data generators. We can inherit from a Bogus faker and share its configuration.
public sealed class AgendaItemFaker : Faker<AgendaItemFaker>
{
public AgendaItemFaker()
{
RuleFor(c => c.Name, f => f.Random.String(1, 10));
}
}
A fake can be used like the following snippet:
var faker = new AgendaItemFaker();
var item = faker.Generate();
I don't use Bogus alone, I always use it in combination with AutoBogus. AutoFaker is a wrapper of the Bogus Faker class and provides conventions and integration into Moq which makes everything fit together.
Our fake looks like this now:
public sealed class AgendaItemFaker : Faker<AgendaItemFaker>
{
public AgendaItemFaker()
{
Configure(builder =>
{
builder.WithConventions();
});
}
}
With this, the effort to write and maintain my test data generators are reduced to a minimum.
Here we are, at the end of the article. Testing code should be as clean and well-maintained as our productive code. My tech stack has been built with the goal of reducing boilerplate code and the maintainability effort of the tests to a minimum.
I'm using the following libraries in combination:
What is your opinion? Do you use a different tech stack? Did I forget something?