How to keep you tests non-flakey

Something I am always striving to avoid in my unit tests is flakiness. That’s why when I needed to deal with a UINavigation bar in the previous version of iMessage, I ended up writing a method that looked like this:

This method puts the responsibility on the client to figure out the runtime of the device, so this method is relatively straight forward and doesn’t suffer from any of the shenanigans that come with embedding lines of code like this, in classes you want to test.

The power of overriding – or always asking for more

A colleague and I in a code review where debating the merits of this approach. The ugliness of exposing these details versus the desire to keep the code clean and testable. Together we came upon the following solution.

Make a public API that is easy and another one that is testable. Then have the public API call the more testable one

So that’s what we did.

The lesson for me here is to always remember you can do anything with software. Got an interface you don’t like? Create a new one. Software is the one disciple where you can have your cake and eat it to. Just create whatever you need, and implement behind the scenes however your like.