When to use unit tests or UI tests

Recorded March 26th 2020 – watch the full episode on YouTube.

When you’re writing tests in Xcode, how do you decide which tests should be unit tests and which should be UI tests?

Ellen Shapiro: I think one good way to think about it is at what point of building are you coming in. If you don't have a facade to test to begin with, then you should be testing from the ground up. Then you should be following that testing pyramid. That's talking about like unit tests, integration tests, UI tests – each one that's simpler, you do more of. And each one that's more complex, you do less of. That strategy of putting a scaffolding up on a facade only works if the facade already exists.

“If you don't have a facade to test to begin with, then you should be testing from the ground up. Then you should be following that testing pyramid. That's talking about like unit tests, integration tests, UI tests – each one that's simpler, you do more of.”

If you're really sort of looking to get started with something and you have an application where you have a pretty good understanding of the code base, you feel like the code base is reasonably well architected. Testing the ins and outs of something simple is a good place to start. Where it's just like, “when I put this in, does the amount that I want come out?” And it sounds like that's really dumb, but one of the key things about unit testing is being able to catch regressions. Basically being able to say, “this used to output 42 and now it outputs 41 – why is that?”

Being able to see that as soon as you have broken it, is really, really helpful. If I'm writing code and then three months later, somebody finds a bug in it, I have to then get back into the mentality that I was in when I was first writing that code three months ago – I've probably forgotten tons of context. It's going to take me considerably longer to fix that bug than it would if I had a test that caught that bug immediately and I would go, “oh, I changed this thing over here. And then this started failing” and “oh, those things are related in a way that I did not realize.”

Having that context makes that bug fix a lot faster. And I think it's something that a lot of places underestimate when they're budgeting how much time should be allotted for tests, because it's definitely something where it's a little bit of eating your vegetables. It's a little bit of like, “hey, you do this thing now you're going to have a lot less trouble later.”

Paul Hudson: A great Jon Reid quote is that tests give us the confidence to make bold changes to our code, because you can rip and replace stuff you want to, and as long as it's green before and green after, you know it's safe.

Ellen Shapiro: Yeah, for sure. And that's definitely when you have a really good test suite, the ability to just sort of say, all right, just throw everything out the window. And let's try this again, and check it still puts out the same output – that's really helpful.

One of the places that I think a lot of advice on testing falls down a little bit is that people are assuming that you're building something new. And personally, I don't usually come into new projects that are new. I come into projects that have been built with varying levels of care.

And it's something where the question of, how do I test this? How do I get this to a point that I want this to be, especially if it has no tests at all. You have to start from someplace known and there's definitely some tricks you can use. Peter Steinberger has a great article about testing with Kif at ludicrous speed. And this works with XCUITest too.

“Because each layer of those tests as you go up that pyramid, the amount of time that it takes to write, the amount of time that it takes to run, all of that goes up.”

But ultimately what it comes down to is setting the speed on your animations. If you set that to a hundred, everything runs a hundred times as fast and it's amazing. It's definitely something that can shave a considerable amount of time off of a large UI test suite. And also it's super fun to watch your computer just fly through things, and just look like it's absolutely on crack. Again, I think if you're starting from scratch, start with the test pyramid and that's also true for adding a new feature to an existing code base. Start by testing the smallest pieces of logic you have, then make sure those pieces of logic work together, then make sure that it shows up on screen the way that you want it to.

Because each layer of those tests as you go up that pyramid, the amount of time that it takes to write, the amount of time that it takes to run, all of that goes up. And you know, the more stuff that you can test without having to put in anything on the screen, the better, but I think it is something where a lot of advice about testing starts from scratch and not from, “hey, I got this giant nest of Vipers from the previous developer who was abducted by aliens.”

I think my favorite one was I had colleagues who got a code base, where they determined the reason that they got the code base was because the previous developer was in jail for selling methamphetamines. Yeah, that's not ideal!

Sponsor Hacking with Swift and reach the world's largest Swift community!