Test-driven development is awesome. Tests are written for the code, watch the tests fail (because the code doesn’t yet exist), then implement the appropriate code and everything works like magic. While writing software this way will save time in the long run, the process creates a large burden up front. This type of testing is wonderful for testing internal business logic, account management, or anywhere the code could get tricky. These individual components may work great, but how do you test that everything *works* from start to finish? Let’s take a look.
Several popular web frameworks, including Ruby on Rails, have excellent automated testing services available such as Cucumber and RSpec. Unfortunately, testing frameworks on iPhone have been fairly lacking until recently. GHUnitTest can run unit tests on individual methods, which allows a developer to confirm that every method does what is expected. Kiwi allows for more behavioral testing like RSpec, which allows setup of a specific scenario (i.e.: “Star this song as my favorite”0 and check that the expected behaviors occur.
While human testing is necessary to test new features as they are built, a method of quickly performing regression is also needed to verify the features built prior still work as expected. Enter KIF (Keep It Functional) for iOS. KIF uses an under-used part of iOS development: accessibility labels. iOS users with vision difficulties can use a screen reader to read the accessibility labels attached to each view on their screen. These labels do not have to match the exact written text – and in many cases say things like “Sign in Button” or “Options Button”, even when the button is just a gear icon. KIF testing is organized into controllers. Each controller contains scenarios. Scenarios are defined for each application features. Each scenario has five main features available for us to use:
- Wait for one of the invisible accessibility labels with certain text to appear
- Tap on a specific point on the screen
- Enter text into a text field
- Tap on an accessibility label
- Wait for notification of an event
As an example, playing a favorite station scenario within a streaming music app may run like this:
- Application launches, wait for “Main Menu” accessibility label to appear
- Tap on view with “Account Button” accessibility label
- Wait or “Account Screen” to appear
- Tap on view with “Sign in” accessibility label
- Enter a test username and password into the text fields
- Tap on “Sign In” button
- Wait for Main Menu to appear again (the account screen will close automatically once signed in)
- Tap on “Menu”
- Wait for a cell in the tableview with a “favorite station” accessibility label to appear
- Tap on the cell
- Wait for the music player to appear
- Wait for a button with the accessibility label “Pause Button” to appear – this means the music has begun playing
- Tap the “Hide Player” button
- Wait for the return to the Main Menu
As I mentioned earlier, automated tests are awesome. Having code that verifies itself lets the development team ensure they are writing top-notch applications. Using KIF to program a user’s interaction, dev teams rely on these automated tests so they can continue application work as usual without having to manually perform full regression tests on each build. Human testers are free to concentrate on new features and bug fixes. Both testers and developers can rest secure knowing they’ll be notified if anything failed. As an added bonus, KIF forces developers to detail accessibility labels for the application, so iOS users with vision difficulties can still enjoy the application. Come by the ChaiOne office, you’ll see these tests run on our welcome screen, taking you step by step through the awesome applications we’re building.