In this video, learn how to write the LayoutTest test. Kyle goes over the methods and protocols in the library you need to implement, and how to run the test on your view. Learn about creating an extension on the class you wish to test where you write the logic to provide the data and sizing information. Plus, learn how to use the XCTestCase subclass, LayoutTestCase, in order to run your LayoutTest.
- [Instructor] You've now specified the data to test your view, now it's time to write the actual test. In this short video, you will learn how to write, and run a layout test, test case. In your exercise files, go to the folder 02_02, and open up the Begin state project there. As you see, this is the same place where we stopped in the last video. So if you haven't watched that video, please do. You see we may have an error here, that's just because we haven't run the test yet, and it hasn't picked up the LayoutTest framework.
Let's do that now. Just hit Command-U, to run all the tests. We don't have any actual layout tests done yet, so it's not actually going to run any tests. Our no tests succeeded. Now we're going to create a new file for our layout tests. We're going to click on the UsingTestDataTests folder, again go to File, New, or Command-N. This time we're writing our actual layout tests. As I said, it's built on top of the XCTest framework, so we're going to use the Unit Test Case Class.
We're going to call this our view name, EntityRowViewLayoutTests. But our subclass is going to be LayoutTestCase. We're going to create it in that folder, make sure it's with the target of the test framework, and here we go. Now make sure we import LayoutTest, or else nothing is going to work. And, we again want to do testable import, the actual app.
Now our warnings and errors should go away. I'm going to remove all of this extra code it gives us by default. And what we're going to be doing, is writing one test, function testLayout. You can call it whatever you'd like, as long as it has test as the prefix. XCTest automatically takes anything with the test prefix and runs it as a test. Now here's the magic of LayoutTest. What we're going to do, is type the runLayoutTests method, going to pick the one that has a view provider, and validation.
And our view provider, is what we set up in the last video. If you remember, the EntityRowView has an extension on it, that implements the view provider protocol. So here, we are going to give EntityRowView.self, for the view provider. Now since this is a trailing closure, we can use the trailing closure syntax. I'm going to close the parenthesis there, and create my closure here. Now we need to name the types here. View, data, and context.
To make this easier, we're also going to specify the type of the view, EntityRowView. This method is going to run the test on all data for this view. So as I said before, LayoutTest automatically loops through all of the different combinations. This method, is going to run this validation closure on each combination of data. All the automatic tests will also be run for you. So without writing anything, we can run this now, and get all of the automatic tests for free. Let's try that first.
Let's hit Command-U, or just click on the one test we want to run. Oh no, it failed. Let's see what failed. This is an important error to think about, that I should've done originally. And it's a very good way to remind yourself. This is saying that the UIButton has no accessibility label. If a button needs to be tapable, if someone is using voiceover, they really need for that to be read.
So, we're going to go in here, and fix this real quick. Let's go to the EntityRowView, go to our one UIButton, go to the third tab here, the document inspector, the identity inspector, and go to the accessibility label, and put in "Share Button". This will solve this issue, and make the button see-able by voiceover, which will allow our users using accessibility, to access it. It's that simple. Let's re-run.
Now everything passes, great. Now we want to write assertions specific to our layout. These are things that should hold true, no matter what the data is. For instance, if we look at our view, the name should be above the subtitle, the person, or company placeholder image should be to the left, and the share button should be to the right. Let's write this in our layout test. Our view has a property, a subtitle.
We want to make sure this is below another view, which is the nameLabel. As you see, LayoutTest gives you these convenient methods to check these things, like below, above. We're also going to check that the title is to the left of the image. So the nameLabel, I may accidentally say title sometimes, if you forget what method you want to use, like I am right now, you can Command-Click on below, and you can see the other ones that are available. So we see below, above, with nice documentation.
After, turns whether a view is after another view on the horizontal axis, so that's what I want here. So I'm, going to say the name label, should be after the image view. We're also going to say that the name label should be before the button. We also want the name label, and the subtitle label, to be left aligned with each other, or leading edge aligned. So we're going to say, nameLabel.leadingAligned, to the subtitle label.
And we can also throw one more in for good measure, and say the subtitle label, should be before the share button as well. No reason to have the subtitle label after the entityImageView, because we're already saying the subtitle label, and the name label, are leading edge aligned. So this should cover all of the different cases we want to test, and make sure that our layout holds. No matter what type of data there is. Let's try running this.
And they succeed. That means I made my layout properly. Let's put a break point at the top here, just to see that it's running with multiple different sets of data. Now when we run... We're going to see it stop here. And if I hit continue, see it stops here again. And it's going to keep doing that. We can also take a look at the data, and see what there is. Let's print this.
As you see, we have the subtitle, which has "Normal length string", we have the name label has "name", and we have the entityType, is company. If we go again, and we print it out again, we'll see different information here. As you see, now we have name has an extremely long string, subtitle has a normal length string, and entityType is company.
So as you see, this keeps looping through, running all of our tests, to make sure everything holds, on each different data combination. We can remove this break point, and continue, and the test finishes. To show or hide this debug area here, we can hit Command-Shift-Y. That's it, you've now tested your view with all different combinations of test data. You've also asserted that all of the automatic tests that LayoutTest provides pass. And the specific conditions for your layout that you want to hold true, are correct for all different combinations of data.
- Installing the library
- Specifying test data
- Reviewing property-based testing
- Using test data and writing the LayoutTest test
- Testing views at different sizes
- Debugging with snapshots
- Dealing with common errors
- Advanced debugging tips
- Exploring catalog view