Learn how to write a clean unit test.
- [Voice Over] Okay, so let's write our first test. If you come over here to the left in the inspector, and expand the FilmFestsTests folder, you'll that we have a default file. Now, inside here we have: a set up, tear down functions, these do pretty much exactly what they say. Anything you need to do, before a test runs, you put in the set up, everything you need to clean up, goes in the tear down. This test example, and the test performance example, these are boiler plate, and we don't really need these because we're going to delete this file, and start a brand new one, but just so you guys the anatomy of a default XCTestCase.
Finally, this line right here, this is the most important line. It, basically, let's your test have access to your application target, so don't forget this. So, what we're going to do here inside our test folder, is great a new test case. So, iOS, Unit Test Case Class, and, I'm going to name it MovieStrucTest. Make sure that the subclass is set to XCTestCase, and we're going to create it.
We're going to just delete the FilmFestTest file. We don't need it anymore. Remove the reference and let's get started. So in here, we're going to delete the boiler plate test that we have. We're going to add our all important testable, import line. And we are all set to go. So what we're going to do, in this test case file, is make sure that every MovieStruct that we instantiate has a title, and/or a release state. This structure doesn't exist yet, but you know, following the red-green refactor method, we want to write a failing test first, and then write the code to pass it.
So let's get started. We're going to write out first test here, func testInit_SetMovieTitle Now, every test case function needs to start with the word test. That's just how it is. You want to be really, really specific in how you name things following that. Usually, it's what you're testing, in this case it's the initializer for our movie structure, and, what you expect the result to be.
So, I expect the movie title to be set. So, what we need to do first is declare a movie, it's going to be of our movie structure type, it's going to take in a title as a string, we're going to call this Summer Blockbuster. And, right now, we should have a failing test. Perfect. This is exactly what we want. Use of unresolved identifier 'Movie'. So, yeah, we don't have a movie structure yet. So we go back to FilmFest target, we're going to make this file right now.
You can name it movie, we're going to create, we're just going to declare a very bare bones struct. Called Movie. Wonderful. Save that off and go back to your test. That's going to resolve one of our errors. The other error, if we run the test, and you can do this either by Command + U, or go into the Product toggle in the upper menu, and hitting test. So let's get back to the error. This error says: the argument passed to call that takes no arguments.
Well, that's true. So what we need to do is go back to our movie struct, say okay, we actually need to declare a title variable. This is going to be of type string. So, if we run our tests, see what happens. Okay, so we have our first passing test. But it doesn't exactly do what we want it to do. So, right now, we could fix this error, or this warning, because it says that, our movie instance is never being used.
It's instantialized, but it's never used. So, what we're going to do is assert something. These are very important in test driven development. So we're going to use an XCTestAssertEqual, we're going to get the warning out of here, so that we can actually see what we're doing. This takes two expressions, and it's going to evaluate them. So we want to check if our movie.title is equal to Summer Blockbuster. We're going to remove that error break point.
And, we're going to run our test. Okay. So now, we've got our first running test. We're initializing a movie. With a title. And then we're asserting, which is really just checking, if our movie.title is equal to what we set it as. And if it is, then our test passes. And that's exactly what we made happen. We're using the default initializer, for the structure, and it's going to set whatever you pass into the title.
So now that we've got that done, we know how to write a test, we know how to run it, and we know how to check it. So we're going to continue, and expand the data model even more.
- Test-driven development: history and theory
- Creating a data model test
- Expanding tests
- Testing class methods
- Checking for duplicates
- Testing table views
- Mocking cells
- Testing cell selection
- Assembling the app