This is a practical example of how to follow the TDD Methodology in conjunction with .NET Core 3.0 and xUnit. 🔋
*Read this in other languages: Portuguese
If you are here, probably you are tired to read/search about TDD, many ways to use but on practice is hard to find a good example. So here, you have your questions answered (really, it's super simple 😄).
TDD is a Test Driven Development methodology. But more than just a way to test your code, TDD is a process, considered a good culture in the companies. TDD Works around a circle with 3 "checkpoints".
-
Red - Create a simple test describing your requirement, it cannot pass (Because you haven't the rules yet 😉). This will help you to avoid false positives.
-
Green - You will implement the business rules code, just enough for the test to pass. No fancy things, for a while.
-
Refactor - The red and green checkpoints create a savepoint, ensuring that your code works fine. Now you can refactor/improve it to make it clean and performatic. 🚩
Simple but...
Don't judge the companies, most of them are trying to change their processes, but they are caught in the middle of it.
For example:
- Difficulty to know how to start
- Learning curve
- Employees resistance
The best way to not feel any of those examples, you need to be ready when this challenge appears. Learning and understanding not just how but why TDD is a good way to code. Helping the processes with:
- Code quality - One best way to start to code is knowing how the scenario works.
- Logic - Having a big picture, you can avoid unnecessary dependencies and couplings.
- Reliability - Being comfortable to solve the problems, therefore, less stress, fewer blocks and saving time.
- Teamwork - Everyone knows what's happening on the code by reading the tests.
- Documentation - Reading the Tests descriptions, the code tells you how the process works.
I separated the requirements by the number ([1 - 2 - 3] - check the commits). Remember the focus here isn't in business methodology, DAL Access, service layers or architecture. I think It would complicate the comprehension. Just focus on the Process 🌝.
Select the xUnit Project.
We create our test class called SpaceBookingRequestTest.cs class with our basic first test ShouldReturnSpaceResultWithRequestValues.
Use the Visual Studio to help you to auto-generate Models SpaceBookingRequest and SpaceBookingResult.
We can also use to create the SpaceBookingRequestExecution.cs and the BookSpace function.
internal SpaceBookingResult BookSpace(SpaceBookingRequest userRequest)
{
throw new NotImplementedException();
}Finalizing this, we'll have our test buildable but not passed (Status: 🔴 ).
On this step, we need to ensure that the simple process is working, implementing the business rules code, just enough for the test to pass. Remember no fancy things for a while (Hold your emotions 😆). For the first test, our "business rule" will be just one set class for the compression.
internal SpaceBookingResult BookSpace(SpaceBookingRequest userRequest)
{
//throw new NotImplementedException(); <--<< Remove this part and implement your Business rules
//Imagine your complexity here xD
return new SpaceBookingResult
{
FirstName = userRequest.FirstName,
LastName = userRequest.LastName,
Email = userRequest.Email,
DateRequested = userRequest.DateRequested
};
}(Status: ✔️)
Having the previous step done, now we can organise/make it "Beautiful" 😁. On the Refactor step, we can clean and organize the solution, obviously ensuring that the tests still working fine. On my example:
- Organize the structure
- Change Internal to Public classes
- Create the Business part separated
- Using Hierarchy (On this example - 1, we have for a while, 2 class with the same code but with different objectives on the next examples).
Having it done, you can create another test, going back to the first step (Red).
I hope you enjoyed this tutorial. I think now, understanding the basics, you can follow the commits to improve your comprehension 😊
Jose Ricardo Cruz
Software Engineer, Microsoft MCSA
You find me here: