Master .NET and C# Unit Testing with NUnit and Moq

What exactly is unit testing and why do we need it? Also, what is TDD?

A summary of the things we've learned in this section of the course.

An overview of the things we'll meet in this section of the course.

More information about ways of issuing warnings in unit tests.

A summary of all the things we've learned in this section of the course.

An overview of different approaches to unit testing.

If you need to run a single unit test on several different sets of data, you can do so using the [TestCase] attribute. ReSharper, Rider and other tools support the running of test cases individually or collectively.

Code coverage tools give you information about the percentage of your code that is actually covered by your tests. Higher values are obviously better, but having 100% coverage is typically a goal not worth going for... unless you have a lot of time on your hands.

Continuous testing means that instead of running tests when you want them to run, you run them on every save or on every compile. Of course, the test runner needs to be smart enough to rerun only affected tests, not every single test that you have in your system.

Control your app's memory consumption with JetBrains' free memory unit testing framework.

An overview of the lectures in this section of the course. Also, source code is attached here!

A discussion of why test doubles are required, and some of the varieties: mocks, stubs and fakes.

A re-worked BankAccount scenario which gets a second component in as a dependency. Oh no, what do we do now?!

Let's build a simple fake object. Nothing to it, really, provided you have an interface you can implement.

A rather advanced approach to building fakes at runtime by defining a DynamicObject that can conform to any interface you might need.

Fakes are great, but if you depend on the behavior of a dependent object for correct operation, what then? We still need to fake it, but the results may need to be different depending on the tests. Stubs to the rescue!

A more powerful incarnation of subs, mocks allow us to do many things, including testing the number of calls of a test double's method. Mocks are typically made through mock frameworks, but we'll roll a simple one ourselves.

A summary of all the things we've learned in this module.

An overview of this, rather large, section of the course that deals with Moq, a mocking framework.

We return to our scenario of a bank account depending on logging and see how we can solve this problem once and for all using the Moq library.

We look at how to mock methods of an object, including an ability to specify particular return values dependent upon the input arguments.

You can direct mock methods to return values which are dependent upon the arguments passed into those methods.

It's also possible to mock methods that have ref or out parameters, sometimes with surprising results.

We look at a few more sophisticated concepts of method mocking, including an ability to provide a functioning method body as well as what happens if you want to mock exception throwing.

Having spent lots of time learning how to mock methods (their arguments and return values), we now turn to properties, which are much simpler.

A mock object's properties, by default, do not behave as properties: instead, they are no-op constructs. But what if you want them to behave like real properties, storing values and yielding them in setters? Well, Moq makes this possible (and easy).

Having figured out methods and properties, we now turn to events: both those based on the typical sender-args arrangement as well as events constructed with custom delegates.

Callbacks allow you to specify custom pieces of code to be invoked whenever some part of a mock object is being accessed. Useful for tracing and ad-hoc profiling.

Verification lets us check that a particular part of a mock object was, in fact, accessed a specific number of times.

Here we look at a few examples of customizing the behavior of mock objects.

If you decide to mock protected members, you need to use a slightly different interface. One unpleasant side effect is that, since those members are protected, you cannot feed their names via either Expression<T> or nameof. The end result is that, unfortunately, those have to be specified as strings, with all the associated performance implications.

A summary of the myriad of things that we've learned in this section of the course.

A summary of all the things we've learned in this course.

Links to my other courses!