TDD Workshop Gdansk

Transcript

1. What is a unit test? 1
2. Wikipedia, from a book on tests “Unit testing is a 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 if they are fit for use.” 2
3. Um… what? 3
4. Wikipedia, from a book on tests “Unit testing is a 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 if they are fit for use.” 4
5. What is an app? 5
6. An app is a set of behaviours created by programmer and expected by user. 6
7. We, programmers, have a limited cognition. As all humans do. 7
8. We can’t always ‘load’ all of the code of our app into our memory. 8
9. This means that we can, by accident, change the behaviour of the app. 9
10. A
11. A B
12. A B
13. A B C
14. A B C
15. Preserving behaviour of complex systems is hard. In fact, of any system at all. 15
16. Enter unit tests. 16
17. Unit test is a failsafe to make sure app behaviour is preserved. 17
18. What is a unit test? 18
19. Unit tests test smallest parts of your code in isolation with test code 19
20. Unit tests test smallest parts of your code in isolation with test code 20
21. Test isolation 21
22. Table Waiter Cook processOrder getDishes 22
23. I’m a cook Table Waiter Cook processOrder getDishes Fake cook 23
24. Why isolate? 24
25. Unit test lifecycle 25
26. Unit test lifecycle • Arrange • Act • Assert 26
27. When a unit test is not a unit test? 27
28. When a unit test is not a unit test? by Michael Feathers 28
29. A test is not a unit test if… • It talks to a database • It communicates across network • It touches the file system • You have to do special things to your environment to run it (edit config files etc) 29
30. A test is not a unit test if… • It talks to a database • It communicates across network • It touches the file system • You have to do special things to your environment to run it (edit config files etc) 30
31. A test is not a unit test if… • It talks to a database • It communicates across network • It touches the file system • You have to do special things to your environment to run it (edit config files etc) 31
32. A 100 ms tests is a very slow test. 32
33. 1500 tests each running 100 ms. That’s 150 seconds. Two and a half minutes. 33
34. Where does TDD fit in all this? 34
35. In TDD you always write test first. Always. 35
36. TDD is not “just adding tests first”. It’s a complete workflow. 36
37. TDD is a great way to “start” when you’re not in the zone… 37
38. … and way to remind yourself what you’ve been working on yesterday! 38
39. TDD is a great way to determine how complex your code has become. You just have to listen. 39
40. Have to fake seven objects to isolate test? 40
41. Have to inject a fake into a fake into a fake? 41
42. This always points to an overcomplicated design. And your tests are here to point that out. Very clearly. 42
43. By writing test first you’re becoming a consumer of your upcoming API. 43
44. Is that API hard to test? 44
45. That means it will probably be hard to consume too. 45
46. Or it will be really hard to maintain. 46
47. What unit tests can’t do? 47
48. Unit tests are never a guarantee that you won’t ship a bug. 48
49. But they’re damn good at greatly reducing amount of bugs. And time spent on QA. 49
50. Are unit tests an invaluable tool for writing great software? Heck yes.
    Am I going to produce a poor product if I can’t unit test? Hell no. Jonathan Rasmusson 50 http://agilewarrior.wordpress.com/2012/10/06/its-not-about-the-unit-tests/
51. Specta 51
52. Specta BDD Testing Framework 52
53. Wait what? BDD? 53
54. Wait what? BDD? Weren’t we supposed to do TDD? 54
55. BDD builds upon TDD by formalising the good habits of the best TDD practitioners. Matt Wynne, XP Evangelist 55 http://blog.mattwynne.net/2012/11/20/tdd-vs-bdd/
56. Good habits 56 • Work outside-in • Use examples to clarify requirements • Use ubiquitous language Thanks Matt!!
57. Technical stuff now 57
58. Specta 58
59. Based on XCTest 59
60. Minimalistic implementation 60
61. Syntax 61
62. }); SPEC_END SPEC_BEGIN(Example) describe(@"Example specs", ^{ 62
63. }); SPEC_END SPEC_BEGIN(Example) describe(@"Example specs", ^{ 63
64. }); SPEC_END SPEC_BEGIN(Example) describe(@"Example specs", ^{ 64
65. }); SPEC_END SPEC_BEGIN(Example) describe(@"Example specs", ^{ 65
66. }); SPEC_END SPEC_BEGIN(Example) describe(@"Example specs", ^{ it(@“should check compiler sanity", ^{ expect(YES).to.beTruthy(); }); 66
67. Describe/Context blocks 67
68. Used to make tests more readable. And isolate behaviour for different scenarios. 68
69. describe(@"NSNumber", ^{ describe(@"when created with the default constructor", ^{ it(@“should have 0 as contained int value", ^{ NSNumber *number = [[NSNumber alloc] init]; expect([number integerValue]).to.equal(0); }); }); context(@"when constructed with an int", ^{ it(@“should have 42 as contained int value", ^{ NSNumber *number = [[NSNumber alloc] initWithInt:42]; expect([number integerValue]).to.equal(42); }); }); }); 69
70. You can have as many nested describes as you want. 70
71. Before/After each blocks 71
72. afterEach(^{ appDelegate = nil; }); beforeEach(^{ appDelegate = [[AppDelegate alloc] init]; }); it(@"should have a window", ^{ expect(appDelegate.window).to.beKindOf([UIWindow class]); }); 72
73. afterEach(^{ appDelegate = nil; }); beforeEach(^{ appDelegate = [[AppDelegate alloc] init]; }); it(@"should have a window", ^{ expect(appDelegate.window).to.beKindOf([UIWindow class]); }); 1 2 3 73
74. Hands on! Let’s write our very first unit test! 74
75. Configuring tests 75
76. Focusing tests 76
77. Focusing tests fdescribe(@"Example specs on NSString", ^{ fit(@"lowercaseString returns a new string with everything in lower case", ^{ fcontext(@"init with damping", ^{ 77
78. PENDING 78
79. PENDING it(@"lowercaseString returns a new string with everything in lower case", PENDING); 79
80. x’ing tests 80
81. x’ing tests xdescribe(@"Example specs on NSString", ^{ xit(@"lowercaseString returns a new string with everything in lower case", ^{ xcontext(@"init with damping", ^{ 81
82. Unit tests results 82
83. Unit tests results How to understand the output? 83
84. Xcode, AppCode, Command Line All give the same results. Devil is in the details 84
85. (…) -[SpecSuiteName passing_spec_name] Test Case '-[SpecSuiteName passing_spec_name]' started. Test Case '-[SpecSuiteName passing_spec_name]' passed (0.271 seconds). -[SpecSuiteName failling_spec_name] Test Case '-[SpecSuiteName failling_spec_name]' started. Test Case '-[SpecSuiteName failling_spec_name]' failed (0.002 seconds). (…) Executed 2 tests, with 1 failure (1 unexpected) in 0.273 (0.278) seconds 2 tests; 0 skipped; 1 failure; 1 exception; 0 pending 85
86. (…) -[SpecSuiteName passing_spec_name] Test Case '-[SpecSuiteName passing_spec_name]' started. Test Case '-[SpecSuiteName passing_spec_name]' passed (0.271 seconds). -[SpecSuiteName failling_spec_name] Test Case '-[SpecSuiteName failling_spec_name]' started. Test Case '-[SpecSuiteName failling_spec_name]' failed (0.002 seconds). (…) Executed 2 tests, with 1 failure (1 unexpected) in 0.273 (0.278) seconds 2 tests; 0 skipped; 1 failure; 1 exception; 0 pending 86
87. (…) -[SpecSuiteName passing_spec_name] Test Case '-[SpecSuiteName passing_spec_name]' started. Test Case '-[SpecSuiteName passing_spec_name]' passed (0.271 seconds). -[SpecSuiteName failling_spec_name] Test Case '-[SpecSuiteName failling_spec_name]' started. Test Case '-[SpecSuiteName failling_spec_name]' failed (0.002 seconds). (…) Executed 2 tests, with 1 failure (1 unexpected) in 0.273 (0.278) seconds 2 tests; 0 skipped; 1 failure; 1 exception; 0 pending 87
88. (…) -[SpecSuiteName passing_spec_name] Test Case '-[SpecSuiteName passing_spec_name]' started. Test Case '-[SpecSuiteName passing_spec_name]' passed (0.271 seconds). -[SpecSuiteName failling_spec_name] Test Case '-[SpecSuiteName failling_spec_name]' started. Test Case '-[SpecSuiteName failling_spec_name]' failed (0.002 seconds). (…) Executed 2 tests, with 1 failure (1 unexpected) in 0.273 (0.278) seconds 2 tests; 0 skipped; 1 failure; 1 exception; 0 pending 88
89. (…) -[SpecSuiteName passing_spec_name] Test Case '-[SpecSuiteName passing_spec_name]' started. Test Case '-[SpecSuiteName passing_spec_name]' passed (0.271 seconds). -[SpecSuiteName failling_spec_name] Test Case '-[SpecSuiteName failling_spec_name]' started. Test Case '-[SpecSuiteName failling_spec_name]' failed (0.002 seconds). (…) Executed 2 tests, with 1 failure (1 unexpected) in 0.273 (0.278) seconds 2 tests; 0 skipped; 1 failure; 1 exception; 0 pending 89
90. Run your tests from command line. 90
91. Seriously, do. It’s pretty awesome. 91
92. “Perfect” setup: Have your tests run each time you change something in a file. 92
93. Enhance your tests output. 93
94. (…) -[SpecSuiteName passing_spec_name] Test Case '-[SpecSuiteName passing_spec_name]' started. Test Case '-[SpecSuiteName passing_spec_name]' passed (0.271 seconds). -[SpecSuiteName failling_spec_name] Test Case '-[SpecSuiteName failling_spec_name]' started. Test Case '-[SpecSuiteName failling_spec_name]' failed (0.002 seconds). (…) Executed 2 tests, with 1 failure (1 unexpected) in 0.273 (0.278) seconds 2 tests; 0 skipped; 1 failure; 1 exception; 0 pending 94
96. Test Output xctool vs xcpretty
97. AppCode 97
98. Jon Reid “AppCode definitely empowers TDD. What I didn't get until I saw someone's screencast is to really lean on Extract Variable to reduce typing.” 98
99. reduce typing 99
100. Resources & Contact @eldudi github.com/mobile-academy/ios-tdd-gdansk pawel@dudek.mobi Code Examples Contact 100