Recorded – watch the full episode on YouTube.
Should test be updated in tandem with app development – should you write your Swift code, write tests, write more code, write tests and so on, or do you do all your coding up front then write all your tests?
Ellen Shapiro: If there's going to be a single commit, if there's going to be a single PR, I want to test everything that's going to be in that PR at the time I'm making that PR. Again, the biggest reason for me to do that, is context. If you lose the context that you had, when you're writing it, writing those tests is going to take you a lot longer.
And I think it's something where sort of understanding like, okay, what is this supposed to do? And being able to sort of have a test for that at the time that you're putting it into the code. You don't have to do the thing of first I write a test and then I write the code and then I pass the test, like the very strict TDD. Because personally that drives me bananas because I don't have that linear thinking process. But the idea of, okay, I want to submit this to my code base. I need to make sure that I have validated that what I'm doing works. I need to also provide a safety net for when I'm changing things in the future. And that's generally when I write tests, because it gives me the advantage of having that backup. And then also still having the context where I'm trying to figure out whether it's doing what I want it to or not.
“If there's going to be a single commit, if there's going to be a single PR, I want to test everything that's going to be in that PR at the time I'm making that PR.”
Paul Hudson: What you're saying is you work in discrete packages, you'll say for this sprint, whether you worked with your work package you're dealing with, you want to do that job, but also write a test for that maybe together, maybe afterwards, but a single package will include the tests and the production code for that work.
Ellen Shapiro: Ideally, yeah. Obviously that's not always possible, but again for me the biggest thing is writing the test when you still have the context. Is really, really, really important, and particularly for me, I have a garbage memory. One of the reasons it was funny. One of the reasons I got my first job is they're like, "You really commented your code, very thoroughly." And I was like, "Yeah, cause I don't remember anything." Well, I didn't say that out loud, but that's basically, the thing is that this is sort of where my garbage memory actually comes in handy. Is that by writing these tests, by having good comments, I'm able to say, "Okay, this is what I was trying to do here."
And be able to sort of have one more thing to jog my memory in terms of what was happening when I wrote this code-
Paul Hudson: So the tests act as documentation is what you're saying? The tests act as documentation for what you're trying to do.
Ellen Shapiro: Yeah. I have definitely found that. And it's definitely something where obviously it's not a substitute for documentation. Please, for the love of God, document your code, but it is something where it provides additional context to that documentation.
And it's also something where I think one of the things that I've long said is that documentation should be the why not the what. It shouldn't just be like, here's a line that's two times three, it multiplies two times three. And that should be like, we need six here because blah, blah, blah, or something like that. It's something where that kind of documentation is so much more useful than just putting a label on stuff.
But it is something where you still need that information about sort of what it's doing in a public API or something like that, where it's like, okay, this is expected to be called from other places. Those other places should know what they're supposed to do with this.
This transcript was recorded as part of Swiftly Speaking. You can watch the full original episode on YouTube, or subscribe to the audio version on Apple Podcasts.
SPONSORED In-app subscriptions are a pain to implement, hard to test, and full of edge cases. RevenueCat makes it straightforward and reliable so you can get back to building your app. Oh, and it's free if your app makes less than $10k/mo.
Link copied to your pasteboard.