Building an Appointment Booking App with Entity Framework and Relational DB

In the previous chapter, we outlined the technical specifications and design decisions for building an appointment booking system for a barber’s salon called Heads Up Barbers. This chapter is a continuation of Chapter 8, Designing an Appointment Booking App, so I strongly advise you to be familiar with what was covered in that chapter first.

This chapter will implement the requirements in TDD style and will use Entity Framework (EF) and SQL Server. The implementation will be applicable to other Relational Database Management Systems (RDBMSs) such as Oracle DB, MySQL, PostgreSQL, and others.

If you are a fan of relational DBs or you are using one at work, then this chapter is for you, whereas if you are using a document database, then you might want to skip this chapter and go to the next one. Both chapters, Chapter 9 and Chapter 10, have the same outcome, but they use different types of backend...

Technical requirements

The code for this chapter can be found in the following GitHub repository:

https://github.com/PacktPublishing/Pragmatic-Test-Driven-Development-in-C-Sharp-and-.NET/tree/main/ch09

To run the project, you will need to have a flavor of SQL Server installed. This can be, Azure SQL, SQL Server Express LocalDB or any other SQL Server flavor.

The implementation doesn’t use any advanced SQL Server features, so feel free to use any. I have tested the application with SQL Server Express LocalDB. You can find more about it here:

https://docs.microsoft.com/en-us/sql/database-engine/configure-windows/sql-server-express-localdb

You can also use any other RDBMS, but you will have to change the DB provider in the code to use the specific .NET DB provider.

To run the project, you have to modify the connection string to your specific DB instance in Uqs.AppointmentBooking.WebApi/AppSettings.json. Currently, it is set to:

"ConnectionStrings"...

Planning your code and project structure

In Chapter 8, Designing an Appointment Booking App, we planned our domain and analyzed what we needed to do. The project architecture will follow the classical three-tier applications of the client application (the website), business logic (the web APIs), and database (SQL Server). Let’s translate this into VS solutions and projects.

In this section, we will create the solution, create the projects, and wire up the components.

Analyzing the project’s structure

Ask a group of senior developers to come up with a project structure, and you will end up with multiple structures! In this section, we will discuss a way of organizing your project structure that I have developed over the years.

Given that we are first going to build a website for the user and later a mobile app (not covered in this book), it makes sense to isolate the business logic to a WebApi project that can be shared by both the website and the mobile app...

Implementing the WebApis with TDD

To build the WebApi project, we are going to look at each requirement from Chapter 8, Designing an Appointment Booking App, and provide the implementation that satisfies it using TDD style.

The requirements are all stated in terms of the Website and its functionality, and they do not dictate how to build our APIs. The Website will have to call the WebApis for any business logic as it has no access to the DB and deals with UI-related business logic only.

This chapter is dedicated to EF for a good reason as we want you to appreciate fakes, which are not as popular as mocks, both from the test doubles family. Also, it will be a typical example of a .NET solution of an ASP.NET Core and a relational DB implementation.

In this section, we will cover working in TDD mode, taking into consideration our persistence provider, EF.

Using the EF in-memory provider

To make our life easier when unit testing the system, we want to abstract the database...

Answering frequently asked questions

Now that we have written the unit tests and the associated implementation, let me explain the process.

Are these unit tests enough?

The answer to this question depends on your target coverage and your confidence that all cases are covered. Sometimes, adding more unit tests increases the future maintenance overhead, so with experience, you would strike the right balance.

Why didn’t we unit test the controllers?

The controllers should not contain business logic. We pushed all the logic to the services, then tested the services. What is left in the controllers is minimal code concerned with mapping different types to each other. Have a look at the controllers in Uqs.AppointmentBooking.WebApi/Controllers to see what I mean.

Unit tests excel in testing business logic or areas where there are conditions and branching. The controllers in the coding style that we chose do not have that.

The controllers should be tested but through...

Summary

We have seen implementing realistic stories by setting up the system with EF and SQL Server, then building it a bit at a time by incrementally adding unit tests and increasing the complexity with every additional unit test.

We have seen a realistic fake test double and a concrete builder to construct our sample data.

We had to select multiple important scenarios to encourage you to examine the full source code, otherwise, the pages will be filled with code.

If you have read and understood the code, then I assure you that this is the peak of the complexity, as other chapters should be easier to read and follow. So congratulations, you have made it through the hard part of this book! I trust you can now go ahead and start your TDD-based project with EF and a relational DB.

Hopefully, this chapter has given you a guide to starting your new EF and SQL Server-based project. The next chapter does the same implementation but focuses on document DB and has different patterns...