Common Challenges & Best Practices for TDD on iOS

TEST DRIVEN DEVELOPMENT
COMMON CHALLENGES &  
BEST PRACTICES FOR
Tokyo iOS Meetup June 2016Derek Lee @derekleerock
ON IOS

COMMON PITFALLS & BEST PRACTICES FOR TDD
YOUR PRESENTER
4/2015~11/2015
12/2015~
1/2014~

WHY TDD?

T
D
D Tokyo iOS Meetup June 2016Derek Lee @derekleerock
Question What is TDD?

TEST
DRIVEN
DEVELOPMENTTokyo iOS Meetup June 2016Derek Lee @derekleerock
Question What is TDD?

WRITE A TEST
MAKE IT PASS
YADDA YADDA YADDA
Challenge Getting over the hump

TDD CRASH COURSE
Challenge Getting over the hump

TESTING WORKFLOW: RED → GREEN → REFACTOR
▸ Write a failing test
▸ Write the simplest implementation
to make it pass
▸ Refactor
▸ Repeat
GETTING OVER THE HUMP

▸ Compiler Errors = Failing Test

▸ Red = Failing Test

▸ Green = Passing Test

▸ Keyboard Shortcuts for improving your test workﬂow:
▸ ⌘ + 5 → Show the Xcode Test Navigator
▸ ⇧ + ⌘ + U → Compile Tests
▸ ⌘ + U → Run All Tests In Suite
▸ MAGIC + U → Run all tests for current class
▸ MAGIC + G → Re-run last test
* MAGIC = ⌃ + ⌥ + ⌘

WRITING TESTS TDD STYLE: ARRANGE → ACT → ASSERT
▸ Setup - Create objects needed to execute the test
▸ Action - Prod the subject (object) under test
▸ Verify - Make assertions about your expectations

▸ Override setUp() and tearDown() methods as needed

▸ Clearly indicate where the “Act” portion of your test is:

▸ Use the appropriate assertion for your test expectation
(XCTest)
let number = 11
XCTAssertTrue(number == 12)
error: -[MyProjectTests.MyObjectTest testMethod] : XCTAssertTrue
failed -

▸ Use the appropriate assertion for your test expectation
(XCTest)
let number = 11
XCTAssertEqual(number, 12)
error: -[MyProjectTests.MyObjectTest testMethod] : XCTAssertEqual
failed: ("Optional(11)") is not equal to ("Optional(12)") -

▸ XCT Assertion Types
▸ AssertTrue, AssertFalse
▸ AssertEqual, AssertNotEqual (+WithAccuracy)
▸ AssertLessThan, AssertGreaterThan (+OrEqual)
▸ AssertNil, AssertNotNil
▸ AssertThrowsError

▸ Nimble (Matcher Framework)
▸ expect(~).to(~) or expect(~).toNot(~)
▸ expect(~).to(beTrue()) or expect(~).to(beFalse())
▸ expect(~).to(beLessThan(~)) // greaterThan…
▸ expect(~).to(beAKindOf(~))
▸ Can also write custom matchers with Nimble

GOLDEN RULES OF TDD
▸ Test First
▸ Simplest Solution
▸ Test Once
▸ Test in Isolation
▸ Test the interface, not the implementation

TDD BEST PRACTICES
▸ One Failing Test at a Time
▸ Create a Test List
▸ Assert First
▸ Simplest Test Data / Evident Test Data
▸ Avoid conditionals and loops

CLASSIC
▸ “Detroit” or “Chicago”
▸ Prefers real objects
▸ Focus: Algorithms
▸ State veriﬁcation
▸ Test doubles as needed
MOCKIST
▸ “London”
▸ Prefers mocks
▸ Focus: Object Interactions
▸ Behavior veriﬁcation
▸ Test doubles always

CONTINUOUS INTEGRATION
▸ Build and test in a clean environment
▸ Automation of your test suite
▸ Test across OSs, simulators, devices
▸ Xcode Server, TeamCity, Travis, CircleCI, Jenkins…

CONTINUOUS INTEGRATION - XCODE SERVER BIG SCREEN

CONTINUOUS INTEGRATION - PIVOTAL PROJECT MONITOR

TAKING THE BLUE PILL
▸ BDD
▸ Clean Architecture
▸ SOLID Principles: SRP, Open/Closed, LSP, ISP, DIP
▸ Don’t Repeat Yourself
▸ Just In Time Design
▸ Refactoring
▸ Continuous Integration

MY TESTS TAKE
FOREVER TO RUN
Challenge The Time-Consuming Test Run

THE TIME-CONSUMING TEST RUN
THE USUAL SUSPECTS
▸ Imbalanced Test Suite
▸ Testing Against External Resources

TESTING ICE-CREAM CONE ANTI-PATTERN

TESTING ICE-CREAM CONE ANTI-PATTERN
▸ Brittle
▸ Expensive to write/maintain
▸ Time consuming to run
UI & MANUAL TESTS CAN BE…

TESTING PYRAMID
]
]
ARE WE
BUILDING
THE RIGHT
SYSTEM?
ARE WE
BUILDING
THE SYSTEM
RIGHT?

TESTING PYRAMID
TIMETOTESTINCREASES

DESIRED TEST SUITE QUALITIES FOR QUICK TEST FEEDBACK
▸ Few
▸ Fast
▸ Stable
▸ Thorough

WHEN TO RUN TESTS
▸ Current Unit/Feature → While building an object / feature
▸ All Units + All Feature → Before commit / push; after
pulling updates from a repo;
▸ Integration, UI → CI Suite
▸ Manual → As needed

WHEN TO RUN TESTS
▸ Create a target for each suite of tests that you want to run

WHEN TO RUN TESTS
▸ Conﬁgure scheme(s) to execute tests:

WHEN TO RUN TESTS
▸ Use a makeﬁle with xcodebuild (or xctool) to execute the
tests when you need to or from CI:
units:
@xcodebuild -project Osusume.xcodeproj -scheme "Osusume" -sdk
iphonesimulator -destination "platform=iOS Simulator,OS=9.3,name=
iPhone 6" build test
integration:
@xcodebuild -project Osusume.xcodeproj -scheme "Osusume-Staging"
-sdk iphonesimulator -destination "platform=iOS Simulator,OS=9.3,
name=iPhone 6" build test

GUIDANCE ON UNIT TESTING - HOW/WHAT TO TEST
▸ Sandi Metz Rails Conf 2013 “The Magic Tricks of Testing”

DO MY TESTS HIT EXTERNAL DEPENDENCIES?
▸ Network, REST APIs
▸ Database (includes Core Data!)
▸ File System
▸ External Library or API

THEN HOW TO TEST EXTERNAL DEPENDENCIES?
▸ Find the seams where communication occurs
▸ Conﬁrm expected interactions using mock objects
▸ Create an integration test if needed

GUIDANCE ON MOCK OBJECTS
▸ Martin Fowler, “Mocks Aren’t Stubs”
http://martinfowler.com/articles/mocksArentStubs.html
▸ Uncle Bob, “The Little Mocker” Blog Post
https://blog.8thlight.com/uncle-bob/2014/05/14/
TheLittleMocker.html

MY TEST SUITE
FEELS UNSTABLE
Challenge The Brittle Test Suite

THE BRITTLE TEST SUITE
THE USUAL SUSPECTS
▸ Highly-coupled objects
▸ Long, complicated, or unreadable tests

HIGHLY COUPLED OBJECTS - DESIGN & ARCHITECTURE
▸ TDD encourages us to write loosely coupled components
that can be easily tested in isolation and combined later.
▸ May need to revisit your architecture
▸ “Build & Swap”
▸ Too difﬁcult or too costly to refactor?
▸ TDD a new component and swap it in

BUILD & SWAP EXAMPLE #1 - DRUM APP NAVIGATION UX

BUILD & SWAP EXAMPLE #2 - MIKADO REFACTOR
▸ Parse Integration Before:
▸ One single “God” object singleton: ParseHelper.h/.m
▸ Included in 25 other classes
▸ Parse Integration After:
▸ 4 Dependency-Injected Testable “Repository” objects
▸ Can move each repository over as needed

HOW TDD HELPS
▸ Design
▸ Loosely coupled objects
▸ Well thought out public object APIs
▸ Dev
▸ Gives immediate feedback on quality
▸ Refactoring conﬁdence

HOW TO APPROACH
▸ Practice, practice, practice
▸ Reference Materials
▸ Read “Refactoring: Improving the Design of Existing
Code” (Martin Fowler)
▸ Read “Working Effectively With Legacy Code” (Michael
Feathers)

I DON’T KNOW
HOW TO TEST X
Challenge Fear of the Unknown

FEAR OF THE UNKNOWN
THE USUAL SUSPECTS
▸ What to test - what not to test
▸ How to test speciﬁc objects, dependencies, scenarios

FEAR OF THE UNKNOWN
KNOWING WHAT NOT TO TEST
▸ Private Methods (this is an implementation detail!)
▸ UI Design (fonts, colors, positions, constraints)
▸ Conﬁguration Details (supporting data)
▸ Auto-generated code
▸ Test Fixtures, Test Doubles
▸ Reference: https://blog.8thlight.com/uncle-bob/
2014/04/30/When-tdd-does-not-work.html

FEAR OF THE UNKNOWN
HOW TO TEST… VIEW CONTROLLERS
▸ Move logic out of MegaController (*Andy Matuschak -
https://realm.io/news/andy-matuschak-refactor-mega-
controller/)
▸ Using Storyboards:
▸ Property Dependency Injection
▸ Without Storyboards:
▸ Constructor Dependency Injection

FEAR OF THE UNKNOWN
HOW TO TEST… CORE DATA
▸ Use an in-memory Core Data Store
▸ Only setup data needed for test

FEAR OF THE UNKNOWN
HOW TO TEST… UITABLEVIEW / UICOLLECTIONVIEW
▸ Extract Datasource and/or Delegate to external object for
easier testing
▸ Leverage blocks / closures for common logic

FEAR OF THE UNKNOWN
HOW TO TEST… NSUSERDEFAULTS
▸ Swift: Mocks in Swift via Protocols (Blog post, Eli Perkins)
http://blog.eliperkins.me/mocks-in-swift-via-protocols
For Objective-C, see OCMock

FEAR OF THE UNKNOWN
▸ Find the method deﬁnition(s) on the object that you need
to conﬁrm interactions with:

FEAR OF THE UNKNOWN
▸ Create your own protocol deﬁnition to duplicate the
method you want to conﬁrm interaction with:

FEAR OF THE UNKNOWN
▸ Create a fake object (spy) that implements that protocol:

FEAR OF THE UNKNOWN
▸ Write your test:

FEAR OF THE UNKNOWN
▸ Write the implementation:

FEAR OF THE UNKNOWN
▸ Pass in the real object for production code:

EASY TO FALL BACK
TO OLD HABITS
Challenge Commitment

COMMITMENT
THE USUAL SUSPECTS
▸ Frustration, Fatigue
▸ Cutting corners
▸ Falling back to what is most comfortable
▸ Test last or not testing at all

TOOLS YOU’LL NEED
▸ Focus
▸ Patience
▸ Tenacity
▸ Discipline
▸ Dedication
COMMITMENT

TIME MANAGEMENT
HOW TO APPROACH
▸ Start Small
▸ 1% each day
▸ Think long-term: Investing in the future of your software

REWARDS OF STICKING TO IT
▸ Making forward progress in small increments
▸ Allows refactoring to take place with conﬁdence
▸ Identify bugs early and avoid regressions
▸ Reduces costs up-front
▸ Add new features knowing you won’t break existing ones
▸ Deploy anytime with conﬁdence
▸ Easier to understand code for you and your team
COMMITMENT

@DEREKLEEROCK
Thank you!

Common Challenges & Best Practices for TDD on iOS

More Related Content

What's hot

Viewers also liked

Similar to Common Challenges & Best Practices for TDD on iOS

Recently uploaded

Common Challenges & Best Practices for TDD on iOS