Testing with Continuous for iOS

In this lesson

  • Explore NCrunch style unit test evaluation
  • Writing assertions with Shoulduous
  • Running a test suite


Tap on time to skip ahead


Intro to Testing with Continuous

With some of my projects when it is applicable, I like to use test driven development to write code – mainly things like business logic, things like view models, services etcetera. And I’ve recently experimented to see what this experience might look like on an iPad using Continuous. So let’s take a look.


Defining a TestSuite

I want to jump ahead, and I’m just gonna go to what the end product of my experiments has been and then go backwards and explain how I did it. So I’m going to open up my TDD examples project here, and we’ll see I just have your standard MyClass that’s auto generated. And here you can see that I’ve created something that looks somewhat similar to what you might see with a Nunit test suite. Now some things that are a bit different than with Nunit is we can’t really use attributes because we’re kind limited on what we can do reflection wise on iOS and with Continuous. So that is why you’ll notice here in the upper right that we are extending TestSuite – versus just using an attribute that says “Hey this is a test suite” like we would with Nunit.


Registering and Running Tests

If we take a look at the constructor for AssertionsTest will see that we’re registering two tests: TestBoolAssertions and TestIntAssertions. And you can see that I’ve also added the option to where you can specify the test name. This will come in handy for when tests fail and we want to know which ones failed. So let’s take a look and see what that does. I’m going to go over to our Watch tab and tap “AssertionTests.” And then we’ll get to our methods, and we’ll see we have a “RunAll” method and this comes from the base TestSuite class. And so I’m gonna go ahead and tap that. And now if I move over to our console will see that we’ll have an output that says “Bool assertions passed…” and “int assertions passed.” And as well as “2 Tests Passed!” This is kind of standard to what we see with a lot of test runners. An additional benefit with Continuous, is at the very top you’ll see that we have “2 Tests Passed” at the top of our UI with a nice little green dot.


Detecting Failing Tests

Now I’m going to go ahead and make some tests fail. So I’m going to said “shouldBeFalse.” And what we will see is at the top will see one test failed and then our test report here on the left will tell us which test failed. So it’s again very are similar to test runners and because Continuous is continuously reevaluating and running the code we write you get a very Ncrunch type of experience as you write your test and code.


Assertions with Shoulduous

Let’s kind of take a look at how I structured this. So one of the things you’ll notice is that for my assertions on use – and what you might have already seen with libraries like Should – and what this is, is a custom project I made and it is called Shoulduous. This is a play on Should and Continuous. And you will see I have ShoulduousExtensions. So as you can see this is basically an extension class where I extend simple primitives like bool an integer and create some handy methods like “ShouldBeGreaterThan” or “Equals” or “ShouldBeLessThan.” And then we have a nice failure message here to the right. And you’ll see at the bottom I have this test function that will run the assertion and if it fails throw the exception.


TestSuite Anatomy

Now this all gets run – or used – inside our TestSuite class. And again this was the class that we extended in our example earlier. In here, we’ll see I kind of have your standard methods like “SetupSuite,” “SetupTest,” “TearDownTest,” and has “TearDownSuite.” This is if you needed to do any set up before you run a test or before and after you run a test suite – which is pretty standard with lots of unit based type of frameworks. And then we’ll see that I have our “Register” method here and which will add our tests to a queue of actions. And then “RunAll” basically goes through here and sees if it’s one that passes or throws an exception. And so as you see it’s very simple with just a few lines a code for both our test suite as well as our assertions extensions. This was a lot of fun to write using Continuous, and I look forward to writing better and more stable applications use on iOS Continuous. 

Additional Info

Register to get access to additional resources and info.