Testing, Turbo Native, and exclusive content.
Sign up for my monthly newsletter.
Hello and welcome to the second edition of The Masilotti Monthly! This month I’m covering Basecamp’s new version of Turbolinks and some new Swift testing techniques I’ve picked up recently.
Turbolinks is dead, long live Turbo ⚡
Turbolinks, my favorite way to build hybrid apps, recently received a huge update.
<body> element with the response.
The native app renders the mobile web view and the frameworks handle the “glue” in between. Think: clicking a link pushes a new controller on the navigation stack. These tools enable small teams of developers to build high-fidelity cross-platform apps. Basecamp, Hey, Zaarly, BeerMenus, and more are all Turbolinks-powered hybrid apps.
Turbo and Hotwire
The web side of Turbo saw a slew of new features and existing things to play with. To show how powerful Turbo is, watch DHH create a live-updating chat application in just 15 minutes. 🤯
The most exciting new feature for the native frameworks is Path Configuration. This moves the URL routing logic to a JSON file. The best part is that this file can live on your server, enabling remote configuration of different URLs. 💪
I’m compiling 5 years of Turbo(links) experience 📓
Since I started working with Turbo(links) in 2015, I’ve been noting all the gotchas and rough patches. I’m slowly compiling these into something more formal to share with the public.
That said, I’m not sure if a book, video course, or blog post series will be the best fit. If you’re interested in learning more about Turbolinks, how would you prefer to learn?
P.S. If you need help on your Turbo(links) project ASAP don’t hesitate to send me an email!
New Swift testing techniques
All three of my most recent blog posts have been around Swift unit testing. I’ve been experimenting with different approaches instead of always reaching for what I know will work.
This post is an alternative to the usual protocol-driven mocking I’m such a huge fan of. Instead, you subclass your dependency and overwrite the functions you need to test.
This approach doesn’t come without its own downsides. First, you can’t subclass a struct! Read Swift mocks without protocols for more information and how I’ll be using this technique in the future.
Probably my favorite post of the month, this one explores a technique I picked up reading the source code of Turbo-iOS.
The goal is to remove the call-verifying properties in your mocks. For example,
private(set) var startWasCalled = false to ensure
start() was called. Instead, all function calls are added to an array which is interrogated in your test expectations.
Even if you don’t work with WebKit, there’s a really interesting XCTest helper in this post you might find interesting.
XCTKVOExpectation is a built-in expectation that listens for key-value observing properties to change. The best part is that you tell it which value you are expecting! That means you can write asynchronous-like tests with very little boilerplate. 👌
Some personal news 🌎
My wife and I have officially moved to Portland, OR! If you know any Rails or iOS devs that are looking to make a new friend, please make a connection.
How do you feel about hybrid? 🤔
A big portion of this edition was focused on Turbo(links) and native mobile apps. Personally, I find them an amazing middle ground for small teams to manage the three big platforms at the same time.
How do you feel about hybrid? I’d love to hear what you think, mention or DM me on Twitter!