Andrzej talked about his personal experience of writing testable apps in Swift and applying DI pattern

1. Testable apps
in Swift
Andrzej Dąbrowski andrzej@amplituda.io amplituda.io

2. A client comes…

3. – Our Beloved Client
“I have a start-up, I need an app, previous team
sucked so I’d like you to continue develop the
project”

4. Great!
Let’s look at the code.

5. 1Split code to independent
single-purpose services.
(no tests without that, sorry)

6. 2Write couple of tests.

7. Example service:
BeaconManager

8. Public API

9. Why should I make a
wrapper around
CLLocationManager?

10. • seamlessly manages permissions
• smoothens out beacon power fluctuations
• doesn’t require all listeners to duplicate single beacon
filtering code and leaving beacon logic
• enable / disable listening
• saves energy (takes care of switching between
monitoring/ranging automatically)
• takes care of background ranging (☠☠☠)
• it’s listeners actually don’t have to care about
anything, only implement code on beacon events.

11. BeaconManager uses
another services/APIs
• CLLocationManager for permissions and
background ranging (updating location)
• Logger (sends critical logs to back-end)
• Data
• SyncManager
• NSNotificationCenter

13. BeaconManager is
critical service to test

14. Singletons.
Hard to test.

15. Objective-C dynamic runtime allows us
easily change implementation of classes /
methods.
OCMock!

16. Can I do this in Swift?
Hmm…

17. Let’s read
http://ocmock.org/swift/

18. There are smart people around who
claim differently:
http://nshipster.com/swift-objc-
runtime/
IMVHO, not the best option.

19. Where is Swift going?
Will there ever be runtime access
in Swift?

20. I have no idea.

21. But if Swift is about to be
super-fast and super-safe,
I wouldn’t count on it.

22. Why Obj-C runtime is so
great in testing?
• Effortless and quick mocks/stubs
• No refactoring needed at all. Just jump into
writing tests.

23. Disadvantages of OCMock
way of testing?
• No compile-time protection
• We can forget to stub some important things
• Encourages a bit to write ugly code (inline mocks /
stubs) which could create problems with duplication
later
• No explicit list of dependencies like in dependency
injection
• Still have to write mocks / stubs :(

24. Alternatives?

25. Stubbing based on abstraction
layer.
Service Locator or DI

26. How does it work?

27. Service Locator

31. Advantages of SL
• compile-time
• quite quick to implement (actually,
sharedInstance properties could be overwritten
so that they call Service Locator themselves).
• Service protocols are a beautiful way to
investigate app architecture without going too
deep into implementation details

32. Disadvantages of SL
• We need to complicate architecture (is that really
bad thing?)
• We can forget to stub some libs
• No explicit list of dependencies (like in DI)
• Still have to write our stubs :(

33. Dependency injection
"Dependency Injection" is a 25-
dollar term for a 5-cent concept.
James Shore

34. "Dependency Injection" is a 25-dollar
term for a 5-cent concept.
James Shore

38. We must initialise services
and inject properties when
app starts.

39. We could use some
automation for initialising
services.

40. Advantages of DI
• compile-time
• explicit list of dependencies (nice app
architecture guard)
• we won’t forget to stub anything
• service protocols are a beautiful way to
investigate app architecture without going too
deep into implementation details

41. Disadvantages of DI
• Quite not-so-fast to implement
• Architecture gets more complicated (like in SL)
• We still need to write stubs

42. SL vs. DI
• http://www.martinfowler.com/articles/
injection.html
• http://bayou.io/draft/
In_Defense_of_Service_Locator.html
• rest of the Internet

43. Are there any libraries for
Dependency Injection?

44. Typhoon
Swinject

45. Typhoon
December, 2012 1667
StarsFirst github commit

46. Swinject
July, 2015 454
StarsFirst github commit

47. There’s a single
disadvantage of all testing
methods.

48. No lib with stubs.

49. I’d like to test like this

50. Why do I have to write
mocks/stubs for Apple or
3rd party libs?

51. Let’s take a look at
modern framework like
angular.js

52. Which iOS frameworks
could be easily stubbed
not to duplicate code?

53. Summary
• method / class swizzling is probably not what you want
in Swift
• service locator is quickest way to get legacy code
tested
• typhoon and swinject are 3rd party libs for Swift testing
• swinject seems to be nice
• unfortunately, there are no libraries which out of the
box give developers stubs / mocks for Apple APIs.

54. Thank you