Posts about software development written by Nick Pachulski
Today I needed to test drive a feature which allows users to confirm their account. Users find their name in a list and tap a “👋 This is Me” button by it. When the button is tapped, they’re sent a text message with a 6-digit confirmation code and asked to enter it into a react native alert prompt, which is also shown on screen after the “👋 This is Me” button is tapped.
Recently I’ve been working on a universal Expo app (iOS, Android & web) intended to help my hockey team keep track of our player and game stats, track who’s RSVP’d to our weekly games, and so on. To keep track of all those things, the Expo app communicates with a restful Ruby on Rails API. I decided, for typical reasons which aren’t the subject of this post, to mock that rails API as I test drove the React Native app.
A vanity metric looks good on paper but doesn’t inform future strategies. It falsely increases confidence. Code coverage can be a vanity metric. 100% test coverage means that the test suite runs every line of production code. That doesn’t mean it exercises the code’s entire intent.
This post will only be helpful to you if you intend to use Joe Masilotti’s strategy for stubbing network data in your UI Tests. You will run into a problem when you try to set a key of app.launchEnvironment to a string with an equals sign in it.
Let’s test drive an even number function