Knowing how to architect and test ASP.NET MVC applications helps you build better apps. In Part 3 of the "Become a Full-stack .NET Developer" series, you'll refactor your app toward a better architecture as well as write unit and integration tests.
Implementing the Remaining Use Cases All right, welcome to Become a Full-stack. NET Developer part three. My name is Mosh Hamedani and I'm going to be your instructor in this course. In the last part we implemented a notification module in our application. Now this part is all about architecture and unit testing. I have to tell you that this is actually my favorite part of the series. From the very first day that I kicked off recording this series I was counting days to get here. In this part, in the first module we're going to finish up the remaining use cases and then we start refactoring our code towards the clean architecture. Once we have a clean and decoupled architecture then we start writing unit and integration tests. Before you get started, ideally you should have gone through the first two parts because there I covered a lot of concepts and techniques. So if you're new to this series, you may wonder why I have done things in a certain way, or you may think I'm coding too fast. If that's the case, you really need to go back and watch this series from the beginning. Also, in this part I'm assuming you have some basic familiarity with unit testing. At least you should have gone through one tutorial and be familiar with assertions and mocking, so I'm not going to teach you unit testing from the beginning. In this part I will show you the proper way to write unit and integration tests for your ASP. Net MVC applications. This part is packed with advanced concepts and I believe if you watch all the videos and do the exercises, you're going to go from an intermediate level developer to a senior developer. Now let's get started.
Refactoring Towards the Clean Architecture In this module, we're going to refactor our application towards the clean architecture,. As Uncle Bob defines, an application with clean architecture is independent of external tools, libraries, and frameworks. So changes to these external dependencies will have minimal impact on our application. In this module, we'll be using the repository and unit of work patterns to decouple our application from editing framework. So, let's get started!
Programming Against Interfaces So in the last module, we used the repository and UnitOfWork patterns to decouple our application from Entity Framework. But the reality is our application is still coupled to Entity Framework because we are directly using the repository and UnitOfWork classes. So to truly decouple our application from Entity Framework, we need to use interfaces. A lot of developers find interfaces confusing because quite often, they are not explained properly in textbooks. So by the end of this module, you'll have a good and in-depth understanding of what interfaces are and how they help us build loosely coupled, extensible and testable applications. Now let's get started.
Testing Controllers All right, this module is all about unit testing controllers. Should we write unit tests, or not? Should we write them before or after the production code? These are the questions that I'm going to answer in this module. A lot of developers have tried unit testing and failed. And that's why they hate it. They argue that unit testing is too costly, and I totally understand that. Poorly written tests are fragile and hard to maintain, and obviously writing them increases the development cost without adding much value. So in this section, I'm going to show you the proper way to write unit tests. Along the way, I will highlight some of the mistakes that many developers make, that makes their unit tests fragile and un-maintainable. So as an example, I'm going to write unit tests for the cancel action in GigsController. You can take what you're going to learn and apply it to any controllers. I can't wait to get started, because I absolutely love my unit tests. So let's get started.
Testing Repositories Okay, in this section, we're going to look at testing our repositories. I'm going to discuss whether we should use unit or integration tests and why. As you will see shortly, the answer to this question is not quite straightforward, and we need to do some assessment on a case by case basis. And then finally, I will show you how to mock the dependencies and unit test your repositories. So let's get started.
Adding Integration Tests So we have covered unit testing controllers, repositories, and domain classes. Unit tests are great for testing algorithms and logic. But every application needs a bunch of integration tests that involve persistence. Without these integration tests, you may run the application and find out that one of the major functions is not working even though all your unit tests passed. Because in unit tests, we mock external resources like a database. So if there are bugs in your persistence layer, your unit tests are not going to catch them. So in this section, you're going to learn how to write reliable integration tests. Now let's get started.