Software Dev

It’s Time for Snapshot Testing

I love the idea of snapshot testing. It’s a simple way to automatically test an app’s UI.

It works like this:

  1. Set the app up in a certain state and take a screenshot. Save the screenshot. πŸ“Έ
  2. Next time when you run the same test, you compare screenshots. πŸ“· πŸ“Έ
  3. If something changed unexpectedly, then you know there’s trouble. πŸ’₯

Here’s a nice series about how to do it for iOS/ Xcode.

πŸ‘‰ Snapshot Testing. Testing the UI and Beyond (Part 1)

And GitHub: swift-snapshot-testing

The coolest thing is that you actually upload your screenshots in any new pull requests, so you can literally see what the change is all about (“The perfect pull request”). 🀯

Image for post

Via iOS Dev Weekly.

Software Dev

How (The Heck) To Test Push Notifications

You know those notifications you get on your phone from Medium, Nextdoor, or NPR? They’re surprisingly hard to develop and test. A lot happens to get that message onto your phone.

And testing them quickly and thoroughly without impacting people you don’t want to impact can be a challenge. So here’s a little guide to the latest way to test push notifications on iOS.

πŸ‘‰ How to test push notifications in simulator and production iOS apps

abc

Via iOS Dev Weekly.

Software Dev

Playbook

Developing features for a large, established app, I often run get slowed down trying to throw together a new screen. You have to find the right spot in the code to update, build the whole app (not just what you changed), log in, and drill down to the right spot to try out your creation. Something’s off? Do it all over again.

Which is why I love the idea of the Playbook library, which is “a library that provides a sandbox for building UI components without having to worry about application-specific dependencies.” Yass! 🀟

πŸ‘‰ Playbook on GitHub

Supports both SwiftUI and UIKit.

playbook

Via iOS Dev Weekly.

Software Dev

DI with Interface Builder

In this dated but thorough Objective-C dependency injection article is a reference to a rather old article asserting that Xcode’s Interface Builder is their “favorite di framework of all time”.

πŸ‘‰ Dependency Inversion Principle and iPhone

I keep feeling frustrated by the added complexity and extra code involved in dependency injection. It can make simple code complex very quickly. So I really love the idea here, which is that Xcode is perfect for DI because it lets you literally just wire up things visually with no extra code. It goes on to make the case for using Interface Builder to wire up more than just UI elements and use it for just about anything.

What’s great about it is that it doesn’t just generate a bunch of code, but instead β€œfreeze dries” real objects to be instantiated when the program loads.

This article is so old that the images don’t load, but I love the ideas and the reminder that DI does not have to involve a bunch of extra code. Thanks to iOS Dev Weekly for the initial link. πŸ‘†