Unit Testing WTWs

A tale about what *surprised* me *while* unit *testing*...

Meetup: https://www.meetup.com/Poznan-iOS-Developers-Meetup/events/230893632/

Transcript

1. Unit Testing WTWs (What the WOWs !!!) !
2. A tale about what surprised me while unit testing...
3. #0 !"#
4. There is always a 1/2
5. Who has never written a unit test in Xcode?
6. Who has !ever written a unit test in Xcode?
7. I have met 3 types of programmers · a few ones that say unit testing is cool ❤
8. I have met 3 types of programmers · majority that say real men ! test on PROD
9. I have met 3 types of programmers · some that don't know how the ! can they start doing it?
10. # 1 WT! a unit test is?
11. Standard bla bla bla... In computer programming, unit testing is a so!ware testing method by which individual units of source code, sets of one or more computer program modules together with associated control data, usage procedures, and operating procedures, are tested to determine whether they are fit for use. — Wikipedia
12. code that tests source code
13. WT! a unit test is?
14. WT! a unit test is? · App = set of behaviours !"
15. WT! a unit test is? · App = component ! + ... + component !
16. WT! a unit test is? · component ← interaction ! → component
17. WT! a unit test is? · unit test = checks(! ← interaction " → !) == ✅
18. Let's write down example behaviours !"
19. WT! a unit test is? "BluetoothModule" "when turned on" "advertises services" "when turned off" "doesn't advertise services"
20. # 2 What the ! spec?!
21. What the ! spec?! · specification ! of our source code
22. What the ! spec?! · spec contains assertions ! (testing code)
23. What the ! spec?! · Use Quick and its ! DSL to create a spec
24. What the ! spec?! · Quick - BDD framework · Nimble - set of matchers
25. What the ! spec?! context("BluetoothModule") { describe("when turned on") { it("advertises services") {} } describe("when turned off") { it("doesn't advertise services") {} } }
26. What the ! spec?! import Quick import Nimble @testable import <#Module#> class <#TestedClass#>Spec: QuickSpec { override func spec() { //!Magic goes here "#$ } }
27. What the ! spec?! Arrange, Act, Assert
28. Arrange, Act, Assert class BluetoothModule { init(peripheralManager: CBPeripheralManagerProtocol) func turnOn() func turnOff() }
29. Arrange phase ! All the world's a stage, ... — Shakespeare !
30. Arrange phase class BluetoothModuleSpec: QuickSpec { override func spec() { context("BluetoothModule") { //i.e. newly initialized var sut: BluetoothModule! var peripheralManager: CBPeripheralManagerProtocol! beforeEach { peripheralManager = MockPeripheralManager() sut = BluetoothModule(peripheralManager: peripheralManager) } afterEach { peripheralManager = nil sut = nil } } } }
31. Arrange phase · context - description of object's state (e.g. object is newly initialised) · beforeEach - local variables setup (XCTest's setup) · a!erEach - local variables cleanup (XCTest's tearDown)
32. Act phase ! ... And all the men and women merely players ... — Shakespeare !
33. Act phase context("BluetoothModule") { //... describe("when turned on") { beforeEach { sut.turnOn() } } describe("when turned off") { beforeEach { sut.turnOff() } } }
34. Act phase · describe - description of action performed on the subject · beforeEach - action on the sut (subject of unit testing)
35. Assert phase ! XCTAssert(true, "Here Shakespeare's quote doesn't fit") — Maciej Piotrowski !
36. Assert phase context("BluetoothModule") { describe("when turned on") { //... it("advertises services") { expect(peripheralManager.isAdvertising) .to(beTrue()) } } }
37. Assert phase context("BluetoothModule") { describe("when turned off") { //... it("advertises services") { expect(peripheralManager.isAdvertising) .to(beFalse()) } } }
38. Assert phase · it - description of desired outcome and test of an expected behaviour
39. #3 What to ! expect?
40. Expect the unexpected...
41. What to ! expect? · Nimble ! provides a number of matchers · Matchers are used in it blocks to assert the expectation ✅
42. What to ! expect? expect(sut.something) .to(equal(5)) expect(sut.somethingDifferent) .toNot(beAKindOf(MyClass)) expect(sut.somethingElse) .toEventually(beNil())
43. What to ! expect? extension MyClass: Equatable {} func ==(lhs: MyClass, rhs: MyClass) -> Bool { return lhs.propertyX == rhs.propertyX && lhs.propertyY == rhs.propertyY && lhs.propertyZ == rhs.propertyZ }
44. What to ! expect? extension MyClass: Equatable {} func ==(lhs: MyClass, rhs: MyClass) -> Bool { return ObjectIdetifier(lhs) == ObjectIdentifier(rhs) }
45. What to ! expect? class class1: NSObject {} class class2: NSObject {} let c1 = class1() let c2 = class2() it("should not be equal") { expect(c1).toNot(equal(c2)) }
46. What to ! expect? it("should be equal") { expect(peripheralManager.delegate as? SDBluetoothModule).to(equal(sut)) }
47. #4 I wish we had mockingjays !
48. What's a Mock?
49. Inject test doubles as dependencies
50. stub - fakes a response to method call
51. mock - lets to check if a call is performed
52. partial mock - actual object altered a bit (some responses faked, some not)
53. W!W. Out of the box mocks are not possible in Swift
54. Swift is currently read-only !
55. There is no way to change class types & objects at run time
56. Communicate with objects through protocols
57. What's a Mock? protocol CBPeripheralManagerProtocol: class { //... weak var delegate: CBPeripheralManagerDelegate { get set } func startAdvertising() func stopAdvertising() }
58. If you don't you will end up with inheritance and partial mocks, which is not recommended...
59. What's a Mock? class MockCBPeripheralManager: CBPeripheralManagerProtocol { //... var startAdvertisingCount = 0 func startAdvertising() { startAdvertisingCount += 1 } }
60. What's a Mock? context("BluetoothModule") { describe("when turned on") { //... it("advertises services") { expect(peripheralManager.startAdvertisingCount) .to(equal(1)) } } }
61. #5 ! Unit test all the things!
62. and mainly interactions between objects
63. But I like to test view controllers!
64. Unit test all the things! ! context("ViewController") { describe("when view loads") { beforeEach { sut.viewDidLoad() } it("does sth") { expect(sut.didSomething).to(beTrue()) } } }
65. What to test?
66. Check if appropriate buttons are set on navigationItem
67. Unit test all the things! ! it("has right button") { expect(sut.navigationItem.rightBarButtonItem) .to(beAKindOf(UIBarButtonItem)) expect(sut.navigationItem.rightBarButtonItem?.enabled) .to(beTrue()) }
68. Check if view controller is tableView's or collectionView's delegate
69. Unit test all the things! ! expect(sut.tableView.delegate as? MyViewController).to(equal(sut)) expect(sut.collectionView.delegate as? MyViewController).to(equal(sut))
70. Check if a tap on a button shows a new view controller
71. Unit test all the things! ! Unit Test Helper comes in handy class UnitTestHelper { class func presentViewControllerModally(vc: UIViewController) {} class func tap(button: UIButton?) {} class func tap(button: UIBarButtonItem?) {} //... }
72. Unit test all the things! ! describe("tap on the right button") { beforeEach { Helper.tap(sut.navigationItem.rightBarButtonItem) } it("shows my other view controller") { expect(sut.presentedViewController) .toEventually(beAKindOf(MyOtherViewController)) } }
73. #6 Do pure Swift objects have load() ?! !
74. Do pure Swift objects have load() ?! ! class MyViewModel { func load() {} } class MyViewController: UIViewController { let viewModel = MyViewModel() override func viewDidLoad() { super.viewDidLoad() view.backgroundColor = UIColor.whiteColor() viewModel.load() } }
75. Do pure Swift objects have load() ?! ! describe("when view loads") { beforeEach { sut.viewDidLoad() } it("calls load on viewModel") { expect(viewModel.loadCount) .to(equal(1)) //ASSERTION FAILURE: expected 1, got 2 } }
76. Do pure Swi! objects have load method?!
77. Do pure Swift objects have load() ?! ! //The view controller calls this method //when its view property is requested but is currently nil. func loadView()
78. What's called a!er loadView?
79. The viewDidLoad method.
80. Do pure Swift objects have load method?! !
81. Pure Swi! objects don't have load method.
82. #7 What is it all f!r ?
83. Testing is not common in iOS development
84. What is it all f!r ? · better understanding ! a codebase
85. What is it all f!r ? · ! well thought architecture
86. What is it all f!r ? · properly documented assumptions !
87. What is it all f!r ? · no fear of making changes !
88. What is it all f!r ? · getting to know ! Apple frameworks better
89. ❤ for fun !!! ❤
90. The time to write unit tests is now.
92. Resources · swi!ing.io - code quality and unit testing · Paweł Dudek - BDD presentastions · objc.io - issue #15 · realm.io - Real-world mocking in Swi!