Real World Testing – Configuring Return with FakeItEasy

In this lesson

  • Use Return to configure the returned result of a fake method call
  • Use description attribute to document expected behavior


Tap on time to skip ahead


So now that we know that our ViewModel is calling the appropriate methods on our user service, we want to test whether or not our ViewModel does the correct thing based on what the user service returns. This is very easy to test with FakeItEasy.


Since our last video, I’ve added a couple more services. I’ve added a navigation service, which is very simple for now. It just has a simple method called GoMain. The idea is, if I successfully log in, then I want to go to the main screen of our application, which might be like a home page, feed, whatever.


The other thing that I’ve created is a prompt service. The prompt service is responsible for presenting things like invalid login, or maybe there’s a server issue. Something along those lines.


We’ve updated our ViewModel to take these two additional services and pass them to our Authenticate command. Because we are using our SetUp method here, that was very easy to add without having to copy and paste in three different places.


Let’s add a new test. Something I’m going to do, is I’m going to use the description attribute so I can describe what is going to happen in this test in a much cleaner way. I’ve experimented using underscores, given then patterns and what not. I prefer to actually read real english text. With this in mind, I’m going to say, “When UserService returns empty GUID, Command should call ShowInvalidPrompt on PromptService.” By doing this, then I don’t have to worry so much about my actual method name test. Test_InvalidLoginPrompt. Let’s update this as well.


We’re going to copy and paste the setting of our email and password. Here, I’m going to say “asdf” for my password. One of the things we need to do is tell our fake user service, “Hey, if you were to get these credentials, return an empty GUID.”  I’m going to say “A.CallTo,” you’ll see this syntax is very familiar to the assertion that we used to verify whether or not a method was called on our user service, “FakeUserService.Authenticate.”


This time I’m actually going to use the values instead of the properties of the ViewModels. By specifying explicitly the strings, you don’t have to worry about something being screwed up with the properties of your ViewModel and thus you’re getting a false positive. “Returns GUID.Empty.” Now we’re saying “Whenever Authenticate is called with these parameters, you want to return an empty GUID.” Now we’re going to say ViewModelUt.AuthenticateCommand.Execute. We now want to verify that the invalid prompt has been shown. I’m going to say, “. CallTo.FakePromptService PromptInvalidLogin.MustHaveHappened.”


If we run this, our test should fail because we’re kind of falling the TDD practice of write a failing test first and then updating your production code to make it pass. I’m going to go into our Authenticate command. I’m going to say, “= GUID.Empty.” Then, we’ll want to say, “PromptService.PromptInvalidLogin.” And now if we go back to our test and run it, it should pass. And it does.


Let’s do the next test, to where if it is a valid login we go to the main screen. I’m going to break a couple rules here. Copy and paste here. This time I’m going to say, “letmein.” We’re going to say, “GUID.NewGUID.” Just to be very diligent, how about we say, “MustNotHaveHappened” as in we don’t want the PromptInvalidLogin to be shown. The next thing we’re going to say “FakeNavService.GoMain.MustHaveHappened.” Again, if we run this it should fail because we want our tests to fail first and then we make them pass by updating our production code. If I go into our Authenticate command I can now say, “Else NavService.GoMain.” If I go back to our test and rerun it, it should pass.


As you can see, it’s real easy with FakeItEasy to set up our fakes to return various things based on the passed in parameters.