Building an App with Repositories and Document DB

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

This chapter will implement the requirements in TDD style and will use the repository pattern with Azure Cosmos DB. The implementation will be applicable to other document databases aka NoSQL such as MongoDB, Amazon DynamoDB, GCP Firestore, and others.

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

The chapter assumes you are familiar with a document...

Technical requirements

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

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

To run the project, you will need to have an instance of Cosmos DB installed. This can be one of the following:

• Azure Cosmos DB on the cloud under an Azure account
• Azure Cosmos DB Emulator, which can be installed locally on Windows, Linux, and macOS and can run from Docker

The implementation doesn’t use any advanced Cosmos feature, so feel free to use any Cosmos flavor. I have tested the application with Azure Cosmos DB Emulator on Windows locally. You can find more about it here:

After installing the local emulator, you need to grab the connection string, which you can do by browsing to https://localhost:8081/_explorer/index.html and copying the connection string from the Primary Connection String field:

Figure 10.1 –...

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 (Cosmos DB). Let’s translate this into VS solutions and projects.

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

Analyzing projects’ structure

Get a group of senior developers to agree on one 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 web API 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 the TDD style.

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

In this section, we will go through working in TDD mode, taking into consideration our persistence provider, the repositories.

Implementing the first story

The first story in our requirement is very easy. The website is going to display all the available services that we have. Since the website will request this data from WebApi through a RESTful API call, the domain layer will have a service that will return this list. Let’s dig further if the website is to display this:

...

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 repositories and Cosmos DB, then building it a bit at a time by incrementally adding unit tests and increasing the complexity with every additional unit test.

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 a document DB.

This chapter ended with the implementation of a realistic project based on TDD. Hopefully, by understanding this part of the book, you are equipped to write your TDD-based project with a relational DB or a document DB.

The next part of the book goes about introducing unit tests to your project...

The rest of the chapter is locked

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 (Cosmos DB). Let’s translate this into VS solutions and projects.

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

Analyzing projects’ structure

Get a group of senior developers to agree on one 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 web API 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 the TDD style.

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

In this section, we will go through working in TDD mode, taking into consideration our persistence provider, the repositories.

Implementing the first story

The first story in our requirement is very easy. The website is going to display all the available services that we have. Since the website will request this data from WebApi through a RESTful API call, the domain layer will have a service that will return this list. Let’s dig further if the website is to display this:

...

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 repositories and Cosmos DB, then building it a bit at a time by incrementally adding unit tests and increasing the complexity with every additional unit test.

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 a document DB.

This chapter ended with the implementation of a realistic project based on TDD. Hopefully, by understanding this part of the book, you are equipped to write your TDD-based project with a relational DB or a document DB.

The next part of the book goes about introducing unit tests to your project...