Refactoring Messy to Testable Code in .NET (Part 8 - Unit Tests)

In this series, we're working through refactoring a messy .NET Core MVC web application with a lot of procedural code and no tests. When we're done, we'll have a more testable, object-oriented, extensible application, complete with unit tests and static code analysis wired up with a continuous integration loop with GitHub Actions. We'll cover topics like inversion of control via dependency injection, replacing conditionals with polymorphism, factory methods, sending messages between small objects, unit testing, naming, and much more!
What is Legacy Code?
“Code without tests is bad code. It doesn’t matter how well-written it is; it doesn’t matter how pretty or object-oriented or well-encapsulated it is. With tests, we can change the behavior of our code quickly and verifiably. Without them, we really don’t know if our code is getting better or worse.”
― Michael Feathers, Working Effectively with Legacy Code
Legacy code - code without tests - is everywhere. It is not unusual in practice to encounter entire applications with few or even no tests. It is perhaps just as common to find software with legacy tests that don't adequately test current software behavior.
As a professional software developer, you will inevitably work on code that is difficult to change and difficult to test. This will be because the original authors of the code (maybe even yourself) didn't understand how to write code that easy to change, didn't understand the importance of unit and integration testing, or perhaps didn't "have time" to write tests for code when it was originally written.
In this course, you'll clone a messy codebase and work step-by-step with me to get it back into shape - complete with tests, continuous integration, and static code analysis! We'll use concepts from object-oriented and functional programming to write cleaner, more testable, more modular code that is easy to change. This is much more than just "DRY" -we'll focus on concepts like:
Extensibility - we'll make it easier to implement new features
Loose coupling - we'll look at how "new is glue," "static cling," and side-effects lead to tightly-coupled software
Minimizing side effects - find out how writing more functional code can prevent unexpected behavior and decrease the chance you'll introduce bugs
Decreasing complexity - often the easiest code to write increases overall complexity - we'll look at how improving your ability to apply slightly advanced techniques can actually decrease the complexity of your application and make it much easier to reason about at different levels of abstraction
Improving naming - notoriously one of the most difficult tasks in software development - what do we call this thing?
Making smaller things - making smaller objects that inter-operate by sending and receiving messages make your codebase easier to maintain, organize, and reason about.

[@matheusaugustodasilvasanto3171]

Another approach for the Deal Service unit tests is to assert the business rules that lead to the values, instead of the values themselves. Here are a few examples:
Does the AM Rate need to be less than the PM Rate?
Does it need to be exactly half?
Should the PM Rate not exceed 10%?
Should the AM Rate not go under 5%?
Answering these questions would inform what assertions should be made in the tests.

[@FizzixGeke]

Hi Wes. This is an excellent series of videos that I will share with my team. Is there more content after Part 8 that you could share with us? Part 8 ends abruptly.

[@sunnypatel1045]

Hi Wes keep up the good work. I been using autofixtures , fluent assertions along with nsubsitute for my unit test

[@manikya.kallimani]

Hi wes doyle, eagerly waiting for your Angular videos. :)

[@AbPSlayer367]

Can you put the final source code in github?

[@amirulrostam5485]

No part 9? Haha.