Your First iOS & SwiftUI App: An App from Scratch

Now that you understand the basics of Unit Testing, I want to introduce you to a way of writing apps that some developers enjoy: Test-Driven Development.

The basic idea of Test-Driven Development is rather than writing tests AFTER you write your code, you write your tests FIRST.

Obviously, at first your tests will fail, because you haven’t written the code yet. But then when you write your code, you have some nice confidence that it works exactly the way you intended it to.

One of the nice things about test-driven development is it forces you to put some thought up-front about how you want your code to work, before you write them. It’s also a great way to ensure you definitely write tests for all your code, instead of forgetting to test some bits. In some cases, it can also result in improved code quality, and increased speed of development.

Note that not every developer likes to use Test-Driven development; and even when developers do, sometimes they only use it for certain parts of their app, like only for the data models.

Basically, whether or not to use Test-Driven Development comes down to a personal choice if this is a way you like to work, or not. We’re going to try out Test-Driven development throughout the rest of the course, and that way you can understand how it works, and if it’s something you might like to incorporate into your workflow in the future.

For this particular episode, we’re going to try out Test-Driven Development to test the Game’s points method. Right now we’ve temporarily hard-coded the method to always return 999. The next item on our programming to-do list is to properly calculate the user’s score.

Again, we could jump straight into implementing the points method, but remember that TDD says you should write your tests first, THEN write the code. So let’s write a few tests that will currently fail, but should work later on once we write the code.

All right, let’s use test-driven development to test out our points method. The way we want it to actually work, not this placeholder, that’s just returning 999.

So we don’t need this example anymore. So I’m going ahead and delete that.

We’re going to add two tests actually. We’re going to add one where the slider value is greater than the target value. And we’re going to add a second test where the slider value is less than the target value.

So let’s start with the first one. So we’re going to type in func test score positive, like so. All of your tests must start with “test” in order for this to work.

Writing this is just like what we learned about methods. We don’t need to pass any parameters into this test, so we can do an empty pair of parentheses here, and then open up with a left curly brace and press tab to close it automagically.

Now inside of the test, we’re going to say, var guess equals game.target plus five. So in other words the random target value, whatever that is, five more in a positive direction away from it.

And then we’ll use our points method to calculate the points for that guess. Say var score equals game.points, pass in “guess” as the slider value.

func testScorePositive() {
  var guess = game.target + 5
  var score = game.points(sliderValue: guess)
}

And then with our values set up, we’ll make our assertion to test. So type XCT Assert Equal and pass in our values to compare.

What do we expect that to be? Well, the way we want both sides to work is currently if you get exactly perfect score, you should get a 100 points. And then depending on how far you’re off from that score you should get fewer points.

So if you’re five away, you should be five less than a 100, in other words, 95 points. That’s the way we want it to work.

So we’ll compare the score to 95.

  XCTAssertEqual(score, 95)

Now I’m going to copy this test, and do another test, but in the negative direction. So I’m going to change from positive to negative for the test name.

And this time we’re just going to go the other way and subtract 5 from the target. So if the target value, for example is 50, the guess would be 45. But you’re still five away, so the score should still be 95 even if you’re negative instead of positive in this case. So, the assertion should be the same.

func testScoreNegative() {
  var guess = game.target - 5
  var score = game.points(sliderValue: guess)
  XCTAssertEqual(score, 95)
}

Now, when we run these tests, these are going to fail. But we should expect that, because we haven’t written the code to actually calculate the score yet.

So our next task is to make these tests pass to prove to ourselves that our points method does what we want it to. And that’s what we’re going to do in the next few episodes.