Writing Unit Tests For Our Applications Via xUnit, FakeItEasy And Shouldly

Background

Usually, we write some unit tests ourselves to cover the code we wrote because unit tests can verify that the component we wrote works fine when we ran it independently.

Sometimes, software developers attempt to save time by doing minimal unit testing or not writing a line of test code. This is a myth that it saves time because skipping on unit testing leads to higher defect fixing costs during Integration Testing, System Testing, and even Acceptance Testing after the application is completed.

Proper unit testing done during the development stage saves both, time and money, in the end.

Based on my limited experience, there are some reasons that make it hard to write unit tests.

Untestable Code.
No idea of unit tests.
Companies don't care about unit tests.
One-time project

The first two are the key reasons.

In this article, I will share how I write unit tests step by step with a sample.

Let's take a look at the components we will use at first.

Components

There are many components that we can use in .NET Core. In this article, I will demonstrate with components that I use often.

xUnit.net

xUnit.net is a free, open source, community-focused unit testing tool for the .NET Framework. Written by the original inventor of NUnit v2, xUnit.net is the latest technology for unit testing C#, F#, VB.NET, and other .NET languages. xUnit.net works with ReSharper, CodeRush, TestDriven.NET, and Xamarin. It is part of the .NET Foundation and operates under its code of conduct. It is licensed under Apache 2 (an OSI approved license).

FakeItEasy

FakeItEasy is a .NET dynamic fake framework for creating all types of fake objects, mocks, stubs, etc.

Shouldly

Shouldly is an assertion framework which focuses on giving great error messages when the assertion fails while being simple and terse.

Example

Suppose we now have several simple scenes.

Create a new user which should have a strong password.
Modify user's password
Delete a user via his/her name but if the name does not exist, we should warn the operator.

Note

In this sample, strong password means that it's not empty and its length is greater than 4.

If we get the requirement for the above scene, how do we start to write our code?

Domains

Before we define a domain class, we should consider what behaviors it should have!

UserInfo must have a method for checking the password whether it is strong or not, so we use it for an example.

The following test methods show us how many test cases we should cover when we write code. As you can see, we just have identified a number of situations that may arise.

public class UserInfoTests
{
[Theory]
[InlineData("")]
[InlineData(" ")]
[InlineData(null)]
public void CheckIsStrongPassword_Should_Return_False_When_Password_Is_Empty(string pwd)
{
}
[Theory]
[InlineData("1234")]
[InlineData("123")]
[InlineData("12")]
[InlineData("1")]
public void CheckIsStrongPassword_Should_Return_False_When_Password_Length_LessThan_Five(string pwd)
{
}
[Theory]
[InlineData("12345")]
[InlineData("123456")]
public void CheckIsStrongPassword_Should_Return_True_When_Password_Length_GreatOrEqual_Five(string pwd)
{
}
// other behaviors...
}

Note

We also can make the test methods fail to substitute for empty test methods.

Next time, we will create a UserInfo class. It contains some import properties and behaviors.

public class UserInfo
{
public int Id { get; set; }
public string UserName { get; set; }
public string Email { get; set; }
public string Password { get; set; }
public bool IsDel { get; set; }
public bool CheckIsStrongPassword()
{
return !(string.IsNullOrWhiteSpace(Password) || Password.Length < 5);
}
// others...
}

Then, we will fill the test methods for the domain class.

[Theory]
[InlineData("")]
[InlineData(" ")]
[InlineData(null)]
public void CheckIsStrongPassword_Should_Return_False_When_Password_Is_Empty(string pwd)
{
var user = new UserInfo { Password = pwd };
var flag = user.CheckIsStrongPassword();
flag.ShouldBe(false);
}
[Theory]
[InlineData("1234")]
[InlineData("123")]
[InlineData("12")]
[InlineData("1")]
public void CheckIsStrongPassword_Should_Return_False_When_Password_Length_LessThan_Five(string pwd)
{
var user = new UserInfo { Password = pwd };
var flag = user.CheckIsStrongPassword();
flag.ShouldBe(false);
}
[Theory]
[InlineData("12345")]
[InlineData("123456")]
public void CheckIsStrongPassword_Should_Return_True_When_Password_Length_GreatOrEqual_Five(string pwd)
{
var user = new UserInfo { Password = pwd };
var flag = user.CheckIsStrongPassword();
flag.ShouldBe(true);
}

The following screenshot shows the test result.

It's really not hard to write unit tests for our application.

The next section will introduce some more complex tests for our business.

Business Layer

Business layer plays a very important role in this article. It contains how to mock up an operation of the database and other related services.

We can write some test cases based on the above requirement.

public class UserInfoBizTests
{
[Fact]
public async Task CreateUser_Should_Return_1001_When_Password_Is_Weak()
{
}
[Fact]
public async Task CreateUser_Should_Return_9000_When_Add_Failed()
{
}
[Fact]
public async Task CreateUser_Should_Return_0_When_Add_Succeed()
{
}
[Fact]
public async Task CreateUser_Should_Trigger_SendEmail_When_Add_Succeed()
{
}
[Fact]
public async Task CreateUser_Should_Not_Trigger_SendEmail_When_Add_Failed()
{
}
[Fact]
public async Task DeleteUser_Should_Return_2001_When_User_Is_Not_Exist()
{
}
[Fact]
public async Task DeleteUser_Should_Return_2002_When_User_Is_Deleted()
{
}
[Fact]
public async Task DeleteUser_Should_Return_0_When_Delete_Succeed()
{
}
[Fact]
public async Task DeleteUser_Should_Return_9000_When_Delete_Failed()
{
}
[Fact]
public async Task ModifyPassword_Should_Return_2001_When_User_Is_Not_Exist()
{
}
[Fact]
public async Task ModifyPassword_Should_Return_1001_When_Password_Is_Weak()
{
}
[Fact]
public async Task ModifyPassword_Should_Return_0_When_Modify_Succeed()
{
}
[Fact]
public async Task ModifyPassword_Should_Return_9000_When_Modify_Failed()
{
}
}

We will define three methods in the IUserInfoBiz interface. Why do we not only add a UserInfoBiz? Because other services may depend on it.

public interface IUserInfoBiz
{
Task<(int code, string msg)> CreateUserAsync(CreateUserDto dto);
Task<(int code, string msg)> ModifyPasswordAsync(ModifyPasswordDto dto);
Task<(int code, string msg)> DeleteUserAsync(DeleteUserDto dto);
}

Also, we should add the Implementclass for it. However, we should add some dependencies at first.

Add a repository named IUserInfoRepository to operate the data but we will not add an Implement class for it, because we don't care how it implements!!

public interface IUserInfoRepository
{
Task<bool> CreateUserAsync(UserInfo userInfo);
Task<bool> ModifyUserAsync(UserInfo userInfo);
Task<bool> DeleteUserAsync(UserInfo userInfo);
Task<UserInfo> GetUserInfoByUserNameAsync(string userName);
}

It's the same as INotifyBiz which contains a method to send email to the user.

public interface INotifyBiz
{
Task<bool> SendEmail(string email);
}

After finishing the definition of dependencies, we can implement the business logic of UserInfoBiz.

public class UserInfoBiz : IUserInfoBiz
{
private readonly ILogger _logger;
private readonly IUserInfoRepository _repo;
private readonly INotifyBiz _notifyBiz;
public UserInfoBiz(ILoggerFactory loggerFactory, IUserInfoRepository repo, INotifyBiz notifyBiz)
{
_logger = loggerFactory.CreateLogger<UserInfoBiz>();
_repo = repo;
_notifyBiz = notifyBiz;
}
public async Task<(int code, string msg)> CreateUserAsync(CreateUserDto dto)
{
// ignore some params check...
// here can use AutoMapper to impore
var userInfo = dto.GetUserInfo();
var isStrongPassword = userInfo.CheckIsStrongPassword();
if (!isStrongPassword) return (1001, "password is too weak");
var isSucc = await _repo.CreateUserAsync(userInfo);
if (isSucc)
{
await _notifyBiz.SendEmail(userInfo.Email);
_logger.LogInformation("create userinfo succeed..");
return (0, "ok");
}
else
{
_logger.LogWarning("create userinfo fail..");
return (9000, "error");
}
}
public async Task<(int code, string msg)> DeleteUserAsync(DeleteUserDto dto)
{
// ignore some params check...
var userInfo = await _repo.GetUserInfoByUserNameAsync(dto.UserName);
if(userInfo == null) return (2001, "can not find user");
var status = userInfo.CheckUserStatus();
if(status) return (2002, "user is already been deleted");
var isSucc = await _repo.DeleteUserAsync(userInfo);
if (isSucc)
{
_logger.LogInformation($"delete {dto.UserName} succeed..");
return (0, "ok");
}
else
{
_logger.LogWarning($"delete {dto.UserName} fail..");
return (9000, "error");
}
}
public async Task<(int code, string msg)> ModifyPasswordAsync(ModifyPasswordDto dto)
{
// ignore some params check...
var userInfo = await _repo.GetUserInfoByUserNameAsync(dto.UserName);
if (userInfo == null) return (2001, "can not find user");
userInfo.ModifyPassword(dto.Password);
var isStrongPassword = userInfo.CheckIsStrongPassword();
if (!isStrongPassword) return (1001, "password is too weak");
var isSucc = await _repo.ModifyUserAsync(userInfo);
if (isSucc)
{
_logger.LogInformation($"modify password of {dto.UserName} succeed..");
return (0, "ok");
}
else
{
_logger.LogWarning($"modify password of {dto.UserName} fail..");
return (9000, "error");
}
}
}

Now, we should fill the test methods!

Due to the fact that UserInfoBiz depends on IUserInfoRepository and INotifyBiz, both of them are not implemented, and we should not be affected by them when we test UserInfoBiz. So, here, we will use FakeItEasy to mock them.

The following code demonstrates how to mock dependent interface and create the test object of UserInfoBiz.

private IUserInfoRepository _repo;
private INotifyBiz _notifyBiz;
private UserInfoBiz _biz;
public UserInfoBizTests()
{
// mock IUserInfoRepository
_repo = A.Fake<IUserInfoRepository>();
// mock INotifyBiz
_notifyBiz = A.Fake<INotifyBiz>();
var loggerFactory = Microsoft.Extensions.Logging.Abstractions.NullLoggerFactory.Instance;
_biz = new UserInfoBiz(loggerFactory, _repo, _notifyBiz);
}

What we should do in the next step is to write the test code.

Here, I choose CreateUser_Should_Return_0_When_Add_Succeed and CreateUser_Should_Trigger_SendEmail_When_Add_Succeed as the two test cases to show.

When CreateUser returns 0, it means the database operation has succeeded.

private void FakeCreateUserAsyncReturnTrue()
{
A.CallTo(() => _repo.CreateUserAsync(A<CoreLayer.Domains.UserInfo>._)).Returns(Task.FromResult(true));
}

The above code tells us that when the method named CreateUserAsync with any parameters was called, it will return Task.FromResult(true).

It's really a good way to avoid the triggering operation of the database when we test our code.

The whole test method of CreateUser_Should_Return_0_When_Add_Succeed is as follows.

[Fact]
public async Task CreateUser_Should_Return_0_When_Add_Succeed()
{
FakeCreateUserAsyncReturnTrue();
var dto = new CreateUserDto { UserName = "catcher", Password = "123456", Email = "[email protected]" };
var (code, msg) = await _biz.CreateUserAsync(dto);
code.ShouldBe(0);
msg.ShouldBe("ok");
}

Now, when we call the CreateUserAsync method of UserInfoBiz, it will always create a new user successfully, no matter if the database is down or there's another infrastructure accident.

Turning to CreateUser_Should_Trigger_SendEmail_When_Add_Succeed--, this test case means that when creating a user successfully, our code should call the SendEmail method of INotifyBiz.

It also means that our code just ensures to call this method, but in UserInfoBiz, we don't care to send email to a user unsuccessfully or successfully, because the result of sending email should consider by INotifyBiz.

So, our test code will look like this.

[Fact]
public async Task CreateUser_Should_Trigger_SendEmail_When_Add_Succeed()
{
FakeCreateUserAsyncReturnTrue();
var dto = new CreateUserDto { UserName = "catcher", Password = "123456", Email = "[email protected]" };
var (code, msg) = await _biz.CreateUserAsync(dto);
A.CallTo(() => _notifyBiz.SendEmail(dto.Email)).MustHaveHappened();
}

Here is the result when we run the test methods.

Here is the source code you can find in my GitHub page.

UnitTestDemo

Summary

This article showed you an easy sample to demonstrate how to write unit tests for our application via xUnit, FakeItEasy, and Shouldly. Also, it suggested that we all should write some unit tests for our applications. Because it has the following advantages.

Reduces Defects in the Newly developed features or reduces bugs when changing the existing functionality.
Reduces Cost of Testing as defects are captured in a very early phase.
Improves the design and allows better refactoring of code.
Unit Tests, when integrated with build gives the quality of the build as well......

I hope this article can help you!