Recorded – watch the full episode on YouTube.
If you have limited time to work, what are the most important things to write tests for?
Ellen Shapiro: I go to, “what is the biggest problem if it breaks?” What are some of the pieces that are holding the whole thing together? Test those. Because by testing those, you may reveal other pieces that you did not realize were part of the thing that holds everything together and that you should also test those.
But it's one of those things where if you accidentally pluralize the end of somebody's name wrongly, that's not going to break your application. That's a little embarrassing, but it's not the end of the world. If you have something where if somebody tries to input like SQLite commands, it accidentally dumps your whole database. That's something that you should probably be aware of. I don't know that you need to necessarily test that, just because Apple does a fair amount of standardization and stuff like that.
But there's not really a whole lot that can necessarily be immediately identified outside of the context of what your app is. Because the context of what your app is, is really, really important to what do I test. Because, again, what are the pieces that are business critical, that are mission critical, that if it breaks, people are coming after you. Those are the things to start with. I think the other thing is just stuff where you're like, "I'm not entirely sure how or why this works." That's a good thing to test.
“What are some of the pieces that are holding the whole thing together, test those. Because by testing those, you may reveal other pieces that you did not realize were part of the thing that holds everything together and that you should also test those.”
I've definitely had the second worst thing in programming is “this doesn't work, I don't know why.” The worst thing is “this works, I don't know why.” And it's definitely something where if you have code or you're like, “this works, and I have no idea why," write a test for it so that if something changes and then it stops working, you can at least sort of maybe start to figure out what happened. That's a place where I would start. I think you can do that with fairly small units of code pretty easily, but it's definitely something where honestly, a lot of it just takes practice. And which is a little bit of a crappy answer because it's like, “where do I start?" Practice, practice, practice. But it's definitely something where again, the more you do it, the more you'll get a sense of what's worth it, and what's not.
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 Spend less time managing in-app purchase infrastructure so you can focus on building your app. RevenueCat gives everything you need to easily implement, manage, and analyze in-app purchases and subscriptions without managing servers or writing backend code.
Link copied to your pasteboard.