DRY Tests with Nunit Setup Attribute

In this lesson

  • Add service dependency to VM
  • Inject Fake for dependency
  • Use “Setup” Nunit attribute to initialize VM under test


Tap on time to skip ahead


In this video, we’re going to explore how we can use more of the Nunit framework to DRY up our testing code. By DRY, I mean the acronym for D.R.Y. which stands for Do Not Repeat Yourself.


Since our last video, I’ve added a few things to our code base. To our UserAuthenticationViewModel, I’ve added the new property called Password. I’ve also created a property for our Authenticate command, which actually needs to be a get and a set property. Otherwise, our Xamarin.Forms binding will not work. Our Authenticate command will actually be an instance of this Authenticate command class that implements the ICommand class interface.


Additionally, I created a new project for our services. Services is a generic phrase for any type of class or code that does a lot of things, like interacting with the res service or file system or does maybe a lot of business logic that is reused across multiple ViewModels.


In this particular instance, I’ve created a user service that will be responsible for authenticating our user. The idea is if the authentication is successful, we will return a valid GUID otherwise, we will return an empty GUID.


Let’s go ahead and start wiring this stuff up. One of the first things I will need to do is instantiate our Authenticate command. I’m going to say AuthenticateCommand = NewAuthenticateCommand. I’m going to trim out this namespace. We’ll see that our Intellisense is telling us that Authenticate command does not take zero arguments. We need to pass IUserService to our ViewModel and in turn pass that to our command, as well as the reference to this ViewModel. Now, when we compile, our ViewModel’s project is nice and happy.


However, if we go into our testing project we’ll now see we have all sorts of red squiggly lines everywhere. That’s because our UserAuthenticationViewModel is now expecting a reference to IUserService.


How can we go about fixing this problem? The first thing I’m going to do is I’m going to add a library called FakeItEasy via NuGet to my Nunit project. What this will allow us to do is easily mock or fake our IUserService. We’re going to reference our IUserService. Then, I’m going to copy and paste this here. Now, when I compile our project should be nice and happy. When I run our tests we should have no problems whatsoever.


Copy and pasting solved this particular problems but if we were to have, let’s say, 20 tests in this particular test suite, it’s probably not a good thing in terms of maintenance and brittleness to just constantly copy and paste this particular line of code. What we’re going to do is we’re going to create a setup method that each test will use. We’re going to use this setup attribute that is provided by Nunit. I’m going to call this InitVmUt. Again, I use the Ut suffix to designate something being under test. Then, I’m going to move this line up here. I’m going to convert my variable into a field and then I’m going to rename it. Now, for each of my tests, I can get rid of this particular variable. I can now use the class property. This class property will get instantiated- or I should say this class field will get instantiated each time this test suite runs a test. Now if I run a test, everything is good to go.


This is how we can use setup to DRY up our code and keep from cluttering up our Nunit test suite with a bunch of initialization code. In the next video I’ll dive deeper into FakeItEasy and how we can use it to actually make sure our ViewModel is doing the appropriate things with our services.