This document discusses testing RubyMotion applications for iOS. It notes that manually building and clicking through apps on devices and simulators is time-intensive, and crash logs can be difficult to decipher, leading to "crash driven development". The document advocates separating business logic from API calls through testing, which encourages object-oriented design and makes it easy to spot bugs and add features. It provides a link to a sample RubyMotion app with testing called Quotidien.

1. DEEP DIVE
BDD with
RubyMotion
Matthew Salerno

2. Me
● Web/Mobile Developer at Cyrus Innovation
cyrusinnovation.com
● Organizer of RubyBlind meetup.
com/rubyblind
● Co-organizer of NYC RubyMotion meetup.
com/NYC-RubyMotion
● Github/Twitter/Blog
github.com/seldomatt
@seldomatt
blog.seldomatt.com

3. TESTING - WHY?
USUAL SUSPECTS
● COURAGEOUS REFACTORING
● EXTENDABLE APPLICATIONS

4. iOS/RubyMotion TESTING
● BUILDING FOR DEVICE/SIMULATOR AND
CLICKING THROUGH IS TIME-INTENSIVE
● CRASH LOGS CAN BE TOUGH TO
DECIPHER
● CDD (Crash Driven Development)

5. SEPARATION
● LOTS O’ COCOA API CALLS
● WRITING TESTS NECESSITATES
SEPARATING OUR BUSINESS LOGIC
FROM API CALLS

6. ● ENCOURAGES OO
● EASY TO SPOT BUGS
● EASY TO ADD FEATURES

7. CODE
QUOTIDIEN
http://github.com/seldomatt/quotidien