Your First iOS & SwiftUI App: An App from Scratch

Heads up... You've reached locked video content where the transcript will be shown as obfuscated text.

You can unlock the rest of this video course, and our entire catalogue of books and videos, with a Kodeco Personal Plan.

Unlock now

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 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 upfront about how you want your code to work before you write it. It's also a great way to ensure that you definitely write tests for all of 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 this 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 games 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 once we've written the code. All right, let's use test-driven development to test out our points method and we're going to test the way we actually want it to work, not just this placeholder that's returning 999. So we don't need this example anymore. So I'm gonna go ahead and delete that. And 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'll add a second test where the slider value is less than the target value. So let's start with the first one. We're going to type in func testScorePositive like so. All of your tests must start with the word 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 automatically. 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 it is, five more in a positive direction away from that. 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 sliderValue. And then with our value set up, we'll make our assertion to test. So type XCTAssert equal and pass in our values to compare. So what do we actually expect that to be? Well, the way we want both sides to work is currently, if you get exactly a perfect score, you should get 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 100. In other words, 95 points. That's the way we want it to work. So we'll compare the score to 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 five 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. 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.