Unit testing is a key component of software testing that developers can handle on their own. It is used to test the smallest components of your code. As you write your code, you may use unit tests to make sure it is working as expected or yielding the desired outcomes.
All developers benefit from testing the code before submitting it to source control. NUnit, xUnit, and other frameworks are among the many available for unit testing. We shall examine the unit testing procedure in this article.
initiative for the Net Web API. Here, we are utilizing the xUnit framework, which is a free and open-source tool, to achieve the same goal. web development. Here, we'll start by addressing the most basic functions.
Creating a Testing Project
At last, we reach the stage where our tests will require the creation of a new project. We will take advantage of the handy xUnit testing project template that comes with Visual Studio 2022 when we use it.
An open-source unit testing tool for the.NET framework called xUnit makes testing easier and frees up more time to concentrate on creating tests:
In order to inject the IEmployeeService interface into our controller during testing, we now need to construct our fictitious implementation of the interface. We are going to populate its in-memory collection with our fictitious data.
public class EmployeeServiceFake : IEmployeeService
{
public readonly Dictionary<Guid, Employee> _employees;
public EmployeeServiceFake()
{
_employees = new Dictionary<Guid, Employee>
{
{
new Guid("503df499-cabb-4699-8381-d76917365a9d"),
new Employee
{
Id = new Guid("503df499-cabb-4699-8381-d76917365a9d"),
Name = "Name1",
Mno = "1234567890",
Salary = 36000,
Type = EmployeeType.Permanent
}
},
{
new Guid("77cf78a6-d6e8-4d50-afeb-39eae4567c62"),
new Employee
{
Id = new Guid("77cf78a6-d6e8-4d50-afeb-39eae4567c62"),
Name = "Name2",
Mno = "1234567890",
Salary = 24000,
Type = EmployeeType.Temporary
}
}
};
}
public bool Exists(Guid id)
{
return _employees.ContainsKey(id);
}
public Guid Create(Employee employee)
{
_employees.Add(employee.Id, employee);
return employee.Id;
}
public void Delete(Guid id)
{
_employees.Remove(id);
}
public List<Employee> GetAll()
{
return _employees.Values.ToList();
}
public Employee GetById(Guid id)
{
if (!_employees.ContainsKey(id))
{
return null;
}
return _employees[id];
}
public Guid Update(Employee employee)
{
var emp = _employees[employee.Id];
emp.Mno = employee.Mno;
emp.Name = employee.Name;
emp.Type = employee.Type;
emp.Salary = employee.Salary;
_employees[employee.Id] = emp;
return employee.Id;
}
}
Write some unit tests, please! We are now prepared to write tests for our EmpController's first GetAll method.
The xUnit framework uses the [Fact] attribute, which we will use to decorate test methods to identify them as the real testing methods. In the test class, in addition to the test methods, we can have an infinite number of helper methods.
The AAA principle (Arrange, Act, and Assert) is typically followed when writing unit tests.
- Arrange: this is the part where you usually get everything ready for the test or put another way, you get the scene ready for the test (making the objects and arranging them as needed).
- Act: Here is where the procedure that we are testing is carried out.
- Assert: In this last section of the test, we contrast the actual outcome of the test method's execution with our expectations.
Testing Our Actions
We will want to confirm the following in the Get method, which is the first method we are testing.
- Whether the method yields the OkObjectResult, a response code of 200 for an HTTP request.
- Whether the returned object includes every item in our list of Emps.
Testing the Get Method
public class EmployeeControllerTest
{
private readonly EmployeeController _employeeController;
private readonly IEmployeeService _employeeService;
public EmployeeControllerTest()
{
_employeeService = new EmployeeServiceFake();
_employeeController = new EmployeeController(_employeeService);
}
[Fact]
public void Get_WhenCalled_ReturnsOkResult()
{
// Act
var response = _employeeController.GetAll();
// Assert
Assert.IsType<OkObjectResult>(response as OkObjectResult);
}
[Fact]
public void Get_WhenCalled_ReturnsAllItems()
{
// Act
var response = _employeeController.GetAll() as OkObjectResult;
// Assert
var result = Assert.IsType<List<Employee>>(response.Value);
Assert.Equal(2, result.Count);
}
}
The class we wish to test is the one in which we create an instance of the EmployeeController object. It's crucial to remember that this constructor is called before every test method, which implies that the test is always run on a new object and the controller state is always reset.
This is crucial because, regardless of how often or in what order we run the tests, the test methods ought to be independent of one another and should yield consistent testing outcomes.
Testing the GetById Method
[Fact]
public void GetById_FakeGuidPassed_ReturnsNotFound()
{
// Arrange
var empId = Guid.NewGuid();
// Act
var response = _employeeController.GetById(empId);
// Assert
Assert.IsType<NotFoundResult>(response);
}
[Fact]
public void GetById_ValidGuidPassed_ReturnsOk()
{
// Arrange
var empId = new Guid("503df499-cabb-4699-8381-d76917365a9d");
// Act
var response = _employeeController.GetById(empId);
// Assert
Assert.IsType<OkObjectResult>(response);
}
[Fact]
public void GetById_ValidGuidPassed_ReturnsEmp()
{
// Arrange
var empId = new Guid("503df499-cabb-4699-8381-d76917365a9d");
// Act
var response = _employeeController.GetById(empId) as OkObjectResult;
// Assert
Assert.IsType<Employee>(response.Value);
Assert.Equal(empId, (response.Value as Employee).Id);
}
Testing the Create Method
[Fact]
public void Create_Invalid_ReturnsBadRequest()
{
// Arrange
Employee? employee = null;
// Act
var response = _employeeController.Create(employee);
// Assert
Assert.IsType<BadRequestResult>(response);
}
[Fact]
public void Create_AlreadyExists_ReturnsBadRequest()
{
// Arrange
var employee = new Employee
{
Id = new Guid("503df499-cabb-4699-8381-d76917365a9d"),
Name = "Name1",
Mno = "1234567890",
Salary = 36000,
Type = EmployeeType.Permanent
};
// Act
var response = _employeeController.Create(employee);
// Assert
Assert.IsType<BadRequestResult>(response);
}
[Fact]
public void Create_ValidEmployee_ReturnsOk()
{
// Arrange
var employee = new Employee
{
Id = Guid.NewGuid(),
Name = "Name1",
Mno = "1234567890",
Salary = 36000,
Type = EmployeeType.Permanent
};
// Act
var response = _employeeController.Create(employee);
// Assert
Assert.IsType<CreatedAtActionResult>(response);
}
[Fact]
public void Create_ValidEmployee_ReturnsResponseItem()
{
// Arrange
var employee = new Employee
{
Id = Guid.NewGuid(),
Name = "Name1",
Mno = "1234567890",
Salary = 36000,
Type = EmployeeType.Permanent
};
// Act
var response = _employeeController.Create(employee) as CreatedAtActionResult;
var emp = response.Value as Employee;
// Assert
Assert.IsType<Employee>(emp);
Assert.Equal(emp.Id, employee.Id);
}
In brief
The test scenarios for our EmployeeController are now complete, and we would like to briefly review some general unit testing guidelines. When writing unit tests, there are a few standards or best practices you should aim for. It will undoubtedly make your life easier and the life of your fellow developers if you respect these practices.
- Readability is a must for unit tests: Nobody wants to waste time attempting to decipher the purpose of your test. Ideally, it should be evident from the test name alone.
- Maintainability is a must for unit tests: It is our goal to write our tests so that even small modifications to the code shouldn't require us to rewrite them all. We should treat our test code the same as the production code in this situation, adhering to the DRY (don't repeat yourself) principle. This lessens the likelihood that someone will eventually reach a point where it is too difficult for them to maintain all of our tests, and they must comment them out.
- Unit sets ought to be quick: People are likely to run tests less frequently if they take too long to complete. That is undoubtedly undesirable, as nobody wants to have to wait around for tests to finish.
- Dependencies shouldn't exist in unit tests: It is crucial that test execution be possible for everyone involved in the project without requiring access to an outside database or system. Testing must be done in complete isolation.
- Make tests reliable instead of just focusing on code coverage: We should feel confident that we can find errors before they are introduced into the production system thanks to well-designed tests. It is simple to write tests that pass and have more code coverage by omitting certain assertions. However, there's no use in doing that. When it comes time to modify the code, we should make an effort to test the appropriate things so that we can rely on them.
In summary
This article has taught us the definition of unit testing and how to set up an xUnit project for unit testing. The fundamental scenarios for testing the controller logic on a few CRUD operations have also been taught to us. You should find these examples to be a great place to start when creating your own unit tests and testing larger, more intricate projects. Thank you for reading, and hopefully, this post will help you understand ASP.NET Core unit testing and concepts a little bit better. We learned the new technique and evolved together. Happy coding!