I noticed Mike Gerasimenko’s new XcodeSelectiveTesting library this week, and it set me thinking about how we run tests in Xcode compared to my previous experience with other development environments.

Mike’s library uses Test Plans to reduce the number of tests that need to be executed based on calculating what tests have been affected by the files you’ve changed. Of course, you’ll still want to run your complete test suite regularly, but when tests break, there are real benefits to getting quick feedback, and running fewer tests is a great way to make your tests run faster!

My main experience developing with other languages comes from writing Ruby code, where I found guard invaluable. It’s a tool that runs alongside your editor and runs any affected tests whenever you save any file in your project. It changed how I used tests, as the effects of any changes were instantly apparent, and I still use it every time I need to change a Ruby project.

Compare that to how I work today, where our test suite on you know what takes over two minutes to run. As a result, I run the tests far less often and sometimes only figure out I’ve broken something when CI tells me. 😬

I know it’s early for feature requests for Xcode 16, and I know that with Swift being a compiled language, it won’t be easy to reach the same level of convenience as seeing test results a second or two after saving a file. However, I’d love to see Apple move towards a model that makes what Mike is doing with XcodeSelectiveTesting unnecessary and towards having Xcode give developers constant feedback from test suites.

Dave Verwer  





Business and Marketing


Software Engineer, macOS @ Raycast – Build something you actually use. Ship every two weeks. No bureaucracy bs. Hack on ideas every Friday. Location-independent salary. Remote, UTC ± 3 hours. – Remote (within European timezones)


Is your company hiring? You can still list open positions for free on iOS Dev Jobs.


And finally...

The Apple & Grand Theft Auto mashup you didn’t know you needed. 🚨