Unit Test with Red-Green-Blue TDD


Tap on time to skip ahead


One of the things I always like to do is create a stand alone new PCL project for just my ViewModels. I’m going to go into Other.Net and I’m going to specify Library. I’m going to call this BetterTests.ViewModels. The reason I like doing this is because then it allows me to easily add a new project for unit tests that is just unit test our ViewModels. Granted, you don’t necessarily have to do it this way, it’s just a convention I like to follow.


I’m going to say BetterTests.ViewModels.Tests. We’ll see that Xamarin Studio has generated our first test fixture for us. If we run our test, you’ll see that one has passed.


One of the things that I’ve done that really speeds up my whole unit testing process, is that I’ve gone into Xamarin Studio’s Preferences, I’ve gone into my Key Bindings, if you do a search, you can see Run Test. I set mine up to the Control T or Control Shift T to run unit tests. This is a great way to speed up your whole Red, Green, Blue cycle.


If you’re not familiar, Red, Green, Refactor is kind of where you write a failing test first, Green is you make that failing tests pass, and then Blue is you refactor or optimize your code. Setting up Key Bindings is a really good way to speed that up.


Just to make sure we have everything set up, I’m going to write an Assert.IsTrue(false). Now, when we run our unit test, we should get a failing test.


Let’s go ahead and set up our first test. We’re going to create a ViewModel and we’re going to call it UserAuthenticationViewModel. This will be the very first screen of our application. If you’re not familiar with ViewModels, I highly suggest you check out some of my other Brax videos where we cover MVVM, which stands for Model View ViewModel.


One of the first things I want to do is I want to have a property for email. I’m going to say Public String EmailAddress. I’m going to say EmailAddress so it is very explicit of what’s going on. Then I want another property. I want this property to signify whether or not the entered email address is valid. We want it to be a bool. EmailIsValid.


Much in the Red, Green, Blue flow, I want to first write a failing unit test. To name this test, we’re going to follow a given Dev pattern. Given_IncorrectEmail_EmailValid_ShouldBe_False. You’ll notice I can’t say, “NewUserAuthenticationViewModel” because I need to add a reference to our project.


I’m going to say, “var vmUT.” I always like to use a UT suffix that signifies this is under test. I’m going to say NewUserAuthenticationViewModel. I’m just going to do a quick build and make sure that works. Then I’m going to say, “vmUT.EmailAddress = “asdf.asdf.” I’m going to say “Assert.IsFalse.” Now, when we run this, we’ll see it passed. This is actually not what we want. That’s because by default, EmailIsValid is going to be false.


What I’m going to do is I’m going to come in here and I’m going to say, “Private bool EmailIsValid = true” and then we’re going to make this a more traditional setter and getter. Now, when we run our application it should fail. Alright.


How do we actually implement this? I’m going to go into my ViewModels project. I’m going to create a new folder called Utils. I’m going to add a regular express utility that I’ve used in our Better Forms series. Copy it over. I’m going to go into it and I’m going to- obviously I’m not the most original person when it comes up to names. BetterTests.ViewModels.Utils. Now I’m going to go into our ViewModel. What we’re going to do is return RegexUtil.ValidEmailAddress().IsMatch. And then, we’re going to get email address. And then,  we’re going to remove our setter. Now, when we run our tests, it should be Green. Then, I can continue testing.


I’m going to write a new test. You really shouldn’t do this. You shouldn’t copy and paste tests, but I don’t want to waste your time. Given_CorrectEmail_EmailValid_ShouldBe_True. Let’s see if it is true. When we run, we should have two tests that are valid.


I didn’t quite do this is the strictest Red, Green, Blue sense but here again, if I just were to return false, we’ll know that that is validating. The test is written correctly. That’s a little bit of a taste of the Red, Green, Blue cycle with TDD.