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?Tokyo iOS Meetup June 2016Derek Lee @derekleerock

T D D


Question What is TDD?

TEST DRIVEN DEVELOPMENT


Question What is TDD?

WRITE A TEST MAKE IT PASS YADDA YADDA YADDA


Challenge Getting over the hump

TDD CRASH COURSETokyo iOS Meetup June 2016Derek Lee @derekleerock

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 workflow:

▸ ⌘ + 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 = ⌃ + ⌥ + ⌘Tokyo iOS Meetup June 2016Derek Lee @derekleerock


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 verification

▸ Test doubles as needed


MOCKIST

▸ “London”

▸ Prefers mocks

▸ Focus: Object Interactions

▸ Behavior verification

▸ 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


TIM

E TO

TES

T IN

CREA

SES


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

▸ Configure scheme(s) to execute tests:



WHEN TO RUN TESTS

▸ Use a makefile 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

▸ Confirm 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


http://martinfowler.com/articles/mocksArentStubs.html

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 difficult 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 confidence



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 specific 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)

▸ Configuration 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


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


https://realm.io/news/andy-matuschak-refactor-mega-controller/

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

http://blog.eliperkins.me/mocks-in-swift-via-protocols

FEAR OF THE UNKNOWN


▸ Find the method definition(s) on the object that you need to confirm interactions with:


FEAR OF THE UNKNOWN


▸ Create your own protocol definition to duplicate the method you want to confirm 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 confidence

▸ Identify bugs early and avoid regressions

▸ Reduces costs up-front

▸ Add new features knowing you won’t break existing ones

▸ Deploy anytime with confidence

▸ Easier to understand code for you and your team


COMMITMENT

@DEREKLEEROCK

Thank you!


Common Challenges & Best Practices for TDD on iOS

Software

Transcript of Common Challenges & Best Practices for TDD on iOS