More Related Content
What's hot
What's hot (19)
Viewers also liked
Viewers also liked (12)
Similar to iOS Unit Testing
Similar to iOS Unit Testing (20)
More from sgleadow
Recently uploaded
Recently uploaded (20)
iOS Unit Testing
- 1. An introduction to unit testing for iOS applications STEWART GLEADOW @stewgleadow Thoughtwor
- 3. Unit Testing
- 6. Unit Testing OCUnit Kiwi Comma nd Line
- 7. Have we been here before? http://sgleadow.github.com/ talks.html#frank
- 8. http://sgleadow.github.com/ talks.html#agileios
- 9. UI Integration Unit http://sgleadow.github.com/ talks.html#agileios
- 10. UI Integration OCUnit GHUnit GTM Unit http://sgleadow.github.com/ talks.html#agileios
- 11. UI Integration Kiwi Cedar OCUnit GHUnit GTM Unit http://sgleadow.github.com/ talks.html#agileios
- 12. Why test in units? We only care if the whole app works.
- 13. Write your tests first. Use tests to design your code
- 14. Write your tests first. Use tests to design your code “Classes typically resist the transition from one user to two, then the rest are easy” - Kent Beck, c2.wiki
- 15. Fast feedback
- 17. Red Green Refact
- 18. but we’re making iOS apps
- 19. THE TOOLS AREN’T GOOD ENOUGH
- 20. THE TOOLS AREN’T GOOD ENOUGH there are too many frameworks to fit here
- 21. NO ONE PAYS YOU TO WRITE TESTS
- 22. NO ONE PAYS YOU TO WRITE TESTS they pay you to write software that works
- 23. SHOULD YOU ALWAYS TEST EVERYTHING ?
- 24. SHOULD YOU ALWAYS TEST EVERYTHING ? “it depends”, says the consultant
- 27. Apple design award here we come
- 29. Getting Started
- 30. Getting Started or, if you’ve already started... http://sgleadow.github.com/blog/2011/10/30/adding-unit- tests-to-an-existing-ios-project
- 31. OCUnit
- 32. OCUnit Application Logic
- 36. @interface FibCounterTests : SenTestCase @end
- 37. - (void)testExample { STFail(@"epic fail"); }
- 38. - (void)setUp { } - (void)tearDown { }
- 40. Controller Tests
- 43. - (void)test_the_fibonacci_number_is_zero_after_reset { ourCounter = [[UILabel alloc] init]; }
- 44. - (void)test_the_fibonacci_number_is_zero_after_reset { ourCounter = [[UILabel alloc] init]; controller = [[SGViewController alloc] initWithNibName:nil bundle:nil]; }
- 45. - (void)test_the_fibonacci_number_is_zero_after_reset { ourCounter = [[UILabel alloc] init]; controller = [[SGViewController alloc] initWithNibName:nil bundle:nil]; controller.counter = ourCounter; }
- 46. - (void)test_the_fibonacci_number_is_zero_after_reset { ourCounter = [[UILabel alloc] init]; controller = [[SGViewController alloc] initWithNibName:nil bundle:nil]; controller.counter = ourCounter; [controller resetCounter]; }
- 47. - (void)test_the_fibonacci_number_is_zero_after_reset { ourCounter = [[UILabel alloc] init]; controller = [[SGViewController alloc] initWithNibName:nil bundle:nil]; controller.counter = ourCounter; [controller resetCounter]; STAssertEqualObjects(ourCounter.text, @"0", nil); }
- 48. - (void)test_the_fibonacci_number_is_zero_after_reset { ourCounter = [[UILabel alloc] init]; controller = [[SGViewController alloc] initWithNibName:nil bundle:nil]; controller.counter = ourCounter; [controller resetCounter]; STAssertEqualObjects(ourCounter.text, @"0", nil); }
- 49. '(null)' should be equal to '0'
- 50. WRITE THE SIMPLEST CODE TO MAKE THE TEST PASS
- 51. WRITE THE SIMPLEST CODE TO MAKE THE TEST PASS - (void)resetCounter { self.counter.text = @"0"; }
- 52. WRITE THE SIMPLEST CODE TO MAKE THE TEST PASS - (void)resetCounter { self.counter.text = [NSString stringWithFormat:@"%u", current]; }
- 53. TEST DRIVE OUR FIBONACCI ALGORITHM
- 54. TEST DRIVE OUR FIBONACCI ALGORITHM 21 0, 1, 1, 2, 3, 5, 8, 13,
- 55. TEST DRIVE OUR FIBONACCI ALGORITHM 21 0, 1, 1, 2, 3, 5, 8, 13, test_the_first_fibonacci_num ber_is_zero test_the_seond_fibonacci_nu mber_is_one test_the_third_fibonacci_nu mber_is_one
- 56. TEST DRIVE OUR FIBONACCI ALGORITHM 21 0, 1, 1, 2, 3, 5, 8, 13, test_the_first_fibonacci_num ber_is_zero - test_the_seond_fibonacci_nu mber_is_one test_the_third_fibonacci_nu mber_is_one
- 57. TEST DRIVE OUR FIBONACCI ALGORITHM 21 0, 1, 1, 2, 3, 5, 8, 13, test_the_first_fibonacci_num ber_is_zero - test_the_seond_fibonacci_nu [controller mber_is_one next]; test_the_third_fibonacci_nu mber_is_one
- 58. TEST DRIVE OUR FIBONACCI ALGORITHM 21 0, 1, 1, 2, 3, 5, 8, 13, test_the_first_fibonacci_num ber_is_zero - test_the_seond_fibonacci_nu [controller mber_is_one next]; [controller test_the_third_fibonacci_nu next]; [controller mber_is_one next];
- 59. '0' should be equal to '1'
- 60. DO THE SIMPLEST THING TO MAKE IT
- 61. KEEP BUILDING YOUR TESTS UNTIL YOU HAVE THE ENTIRE
- 62. MAKE IT AWESOME
- 63. MAKE IT AWESOME (aka - there is a step 3)
- 64. MAKE IT AWESOME (aka - there is a step 3)
- 65. (defun fib (n) (if (< n 2) n (+ (fib (- n 1)) (fib (- n 2))))) MAKE IT AWESOME (aka - there is a step 3)
- 67. SGViewController - (void)next; - (void)resetCounter; Fibber - (NSUInteger)current; - (NSUInteger)next; - (NSUInteger)reset;
- 68. UIButton SGViewController - (void)next; UILabel - (void)resetCounter; Fibber - (NSUInteger)current; - (NSUInteger)next; - (NSUInteger)reset;
- 71. It is possible to test your UIViewController lifecycle and XIB from your “unit” tests
- 73. controller. view * check for non-nil outlets *
- 75. [button actionsForTarget:controll forControlEvent:UIControlEventTo chUpInside] for correct action * check selectors *
- 77. [controller didReceiveMemoryWarning] * check for nil outlets *
- 78. WHAT ABOUT KIWI?
- 79. RSpec Style vs xUnit Style
- 82. SPEC_BEGIN(SGViewControllerSpec ) describe(@"fibonacci number", ^{ context(@"when reset", ^{ }); }); SPEC_END
- 83. SPEC_BEGIN(SGViewControllerSpec ) describe(@"fibonacci number", ^{ context(@"when reset", ^{ beforeEach(^{ // set up code }); it(@"should be zero", ^{ [controller resetCounter]; [[[ourCounter text] should] equal:@"0"]; }); }); }); SPEC_END
- 84. Is it just a change of wording?
- 85. Kiwi comes with mocks and stubs built in
- 86. UIButton SGViewController - (void)next; UILabel - (void)resetCounter; Fibber - (NSUInteger)current; - (NSUInteger)next; - (NSUInteger)reset;
- 87. TESTS ARE EFFECTIVELY TESTING THE PLUMBING
- 88. TESTS ARE EFFECTIVELY TESTING THE PLUMBING it(@"should update label using fibber", ^{ id ourFibber = [Fibber mock]; [[ourFibber should] receive:@selector(next) andReturn:theValue(3)]; controller.fibber = ourFibber; [controller next]; [[[ourCounter text] should] equal:@"3"]; });
- 89. WHAT ABOUT RUNNING TESTS FROM THE COMMAND LINE
- 90. xcodebuild is your friend...
- 91. xcodebuild is your friend... until it unfriends you
- 92. xcodebuild -project FibCounter.xcodeproj -target FibCounterTests -configuration Debug -sdk iphonesimulator
- 93. and hack this file: "${SYSTEM_DEVELOPER_DIR}/Tools/ RunUnitTests"
- 94. and hack this file: "${SYSTEM_DEVELOPER_DIR}/Tools/ RunUnitTests" http://longweekendmobile.com/ 2011/04/17/xcode4-running-application- tests-from-the-command-line-in-ios/
- 95. Resources
- 96. Resources iDeveloper TV Unit Testing Course (Graham Lee) http://ideveloper.tv/video/ unittestingcourse.html
- 97. Resources iDeveloper TV Unit Testing Course (Graham Lee) http://ideveloper.tv/video/ unittestingcourse.html TDD for iOS Tutorials (Doug Sjoquist) http://www.sunetos.com/items/ 2011/10/24/tdd-ios-part-1
- 98. Resources iDeveloper TV Unit Testing Course (Graham Lee) http://ideveloper.tv/video/ unittestingcourse.html TDD for iOS Tutorials (Doug Sjoquist) http://www.sunetos.com/items/ 2011/10/24/tdd-ios-part-1 Prag Prog Magazine http://pragprog.com/magazines/2010-07/ tdd-on-iphone-diy
- 99. Resources iDeveloper TV Unit Testing Course (Graham Lee) http://ideveloper.tv/video/ unittestingcourse.html TDD for iOS Tutorials (Doug Sjoquist) http://www.sunetos.com/items/ 2011/10/24/tdd-ios-part-1 Prag Prog Magazine http://pragprog.com/magazines/2010-07/ tdd-on-iphone-diy Shameless Shameless Plug http://sgleadow.github.com
- 100. THANKS
- 101. STEWART GLEADOW Thoughtworks sgleadow.github.c Talks: om/talks Twitter: @stewgleadow Email: sgleadow@though
Editor's Notes
- \n
- - what is unit testing\n- introduction to ocunit in general\n
- - what is unit testing\n- introduction to ocunit in general\n
- - what is unit testing\n- introduction to ocunit in general\n
- - what is unit testing\n- introduction to ocunit in general\n
- - Frank talk at the first cocoaheads of the year in February\n- thanks to Oliver for editing and uploading video\n
- - balance your tests (Kevin doesn&#x2019;t like this picture)\n- the unit tests are the work horse of your test suite\n- unit = translation unit in compiler speak\n- unit tests don&#x2019;t talk to network, disk, database, Interface Builder\n(the unit testing tools can also be used to write tests for these things,\nbut let&#x2019;s not call them unit tests)\n- xUnit v RSpec style tests\n
- - balance your tests (Kevin doesn&#x2019;t like this picture)\n- the unit tests are the work horse of your test suite\n- unit = translation unit in compiler speak\n- unit tests don&#x2019;t talk to network, disk, database, Interface Builder\n(the unit testing tools can also be used to write tests for these things,\nbut let&#x2019;s not call them unit tests)\n- xUnit v RSpec style tests\n
- - balance your tests (Kevin doesn&#x2019;t like this picture)\n- the unit tests are the work horse of your test suite\n- unit = translation unit in compiler speak\n- unit tests don&#x2019;t talk to network, disk, database, Interface Builder\n(the unit testing tools can also be used to write tests for these things,\nbut let&#x2019;s not call them unit tests)\n- xUnit v RSpec style tests\n
- - balance your tests (Kevin doesn&#x2019;t like this picture)\n- the unit tests are the work horse of your test suite\n- unit = translation unit in compiler speak\n- unit tests don&#x2019;t talk to network, disk, database, Interface Builder\n(the unit testing tools can also be used to write tests for these things,\nbut let&#x2019;s not call them unit tests)\n- xUnit v RSpec style tests\n
- - balance your tests (Kevin doesn&#x2019;t like this picture)\n- the unit tests are the work horse of your test suite\n- unit = translation unit in compiler speak\n- unit tests don&#x2019;t talk to network, disk, database, Interface Builder\n(the unit testing tools can also be used to write tests for these things,\nbut let&#x2019;s not call them unit tests)\n- xUnit v RSpec style tests\n
- - balance your tests (Kevin doesn&#x2019;t like this picture)\n- the unit tests are the work horse of your test suite\n- unit = translation unit in compiler speak\n- unit tests don&#x2019;t talk to network, disk, database, Interface Builder\n(the unit testing tools can also be used to write tests for these things,\nbut let&#x2019;s not call them unit tests)\n- xUnit v RSpec style tests\n
- - balance your tests (Kevin doesn&#x2019;t like this picture)\n- the unit tests are the work horse of your test suite\n- unit = translation unit in compiler speak\n- unit tests don&#x2019;t talk to network, disk, database, Interface Builder\n(the unit testing tools can also be used to write tests for these things,\nbut let&#x2019;s not call them unit tests)\n- xUnit v RSpec style tests\n
- - balance your tests (Kevin doesn&#x2019;t like this picture)\n- the unit tests are the work horse of your test suite\n- unit = translation unit in compiler speak\n- unit tests don&#x2019;t talk to network, disk, database, Interface Builder\n(the unit testing tools can also be used to write tests for these things,\nbut let&#x2019;s not call them unit tests)\n- xUnit v RSpec style tests\n
- - this is partly true, but it&#x2019;s hard to effectively test the whole app\n- need to look at the cost of testing\n-> time to write a test, time to fix a bug when it breaks\n-> want small, focused tests (understand 10 lines of code to fix the bug)\n- unit test boundary conditions / error cases (eg server rubbish)\n- can test things that are unlikely to come up in normal usage but are possible\n
- - fallacy of unit testing is that it&#x2019;s just about asserting behaviour or preventing bugs\n-> bigger benefit is about the design of your code\n- need to write your tests first to leverage this\n- want code with low coupling and high cohesion (that makes it easy to test)\n- doesn&#x2019;t magically make you write good code, but bad code is hard to test\n- want reusable code (code fights being reused a second time)\n- keeps you from writing unnecessary code\n
- - entire unit test suite should take seconds to run\n- if you can&#x2019;t hold your breath while your test suite runs, don&#x2019;t hold your breath that anyone will run it\n- specific errors, right after they occur\n- in context\n
- - see them fail first: it is possible to have bugs in your tests\n- get them passing, only what&#x2019;s needed\n- clean up after yourself while the tests are green (leverage tests)\n- a codebase not only well tested, but well maintained\n(easy to make changes - tests are there to help you)\n- refactor to make it easy to read\n- refactor your tests... but keep them easy to read (bit of duplication is ok)\n- he thought he was being pragmatic, you think he&#x2019;s an idiot\n
- \n
- - true in the past, but not anymore\n- definitely not for unit testing frameworks\n- TDD/CI have been hard but getting better\n- how complicated is a testing framework anyway?\n\n
- - true in the past, but not anymore\n- definitely not for unit testing frameworks\n- TDD/CI have been hard but getting better\n- how complicated is a testing framework anyway?\n\n
- - true in the past, but not anymore\n- definitely not for unit testing frameworks\n- TDD/CI have been hard but getting better\n- how complicated is a testing framework anyway?\n\n
- - that&#x2019;s US dollars\n- I don&#x2019;t have time to write tests\n- 90% of the life of a piece of code is later, more up front = less later\n- if your tests aren&#x2019;t helping you write better software faster, change something\n- tests are easier to write than the main code, but they also make your real code easier\n- confidence to change things: once you&#x2019;re comfortable with working in this way, I find it quicker than not writing tests\n
- - that&#x2019;s US dollars\n- I don&#x2019;t have time to write tests\n- 90% of the life of a piece of code is later, more up front = less later\n- if your tests aren&#x2019;t helping you write better software faster, change something\n- tests are easier to write than the main code, but they also make your real code easier\n- confidence to change things: once you&#x2019;re comfortable with working in this way, I find it quicker than not writing tests\n
- - that&#x2019;s US dollars\n- I don&#x2019;t have time to write tests\n- 90% of the life of a piece of code is later, more up front = less later\n- if your tests aren&#x2019;t helping you write better software faster, change something\n- tests are easier to write than the main code, but they also make your real code easier\n- confidence to change things: once you&#x2019;re comfortable with working in this way, I find it quicker than not writing tests\n
- - testing is ultimately about pragmatism\n- plenty of good programmers don&#x2019;t TDD, I&#x2019;m not dogmatic about it\n- test the most important bits: separation of concerns is important\n- test parts with the most logic / more prone to change more (not less)\n* Models? Yes. Controllers? Probably. IB plumbing? Maybe. Views? Unlikely.\n- can even test position of views and memory, but what does that get you?\n- I want to show you the basics of some things you _can_ test, and how you can test them. It&#x2019;s up to you\n
- - testing is ultimately about pragmatism\n- plenty of good programmers don&#x2019;t TDD, I&#x2019;m not dogmatic about it\n- test the most important bits: separation of concerns is important\n- test parts with the most logic / more prone to change more (not less)\n* Models? Yes. Controllers? Probably. IB plumbing? Maybe. Views? Unlikely.\n- can even test position of views and memory, but what does that get you?\n- I want to show you the basics of some things you _can_ test, and how you can test them. It&#x2019;s up to you\n
- - testing is ultimately about pragmatism\n- plenty of good programmers don&#x2019;t TDD, I&#x2019;m not dogmatic about it\n- test the most important bits: separation of concerns is important\n- test parts with the most logic / more prone to change more (not less)\n* Models? Yes. Controllers? Probably. IB plumbing? Maybe. Views? Unlikely.\n- can even test position of views and memory, but what does that get you?\n- I want to show you the basics of some things you _can_ test, and how you can test them. It&#x2019;s up to you\n
- - I know what you&#x2019;re thinking (boring, or reminds you of project estimation)\n- simple enough that none of us really have to think about how it works\n- algorithmically complex enough that we might screw it up\n(and it takes more than one test to drive a full implementation)\n
- - I know what you&#x2019;re thinking (boring, or reminds you of project estimation)\n- simple enough that none of us really have to think about how it works\n- algorithmically complex enough that we might screw it up\n(and it takes more than one test to drive a full implementation)\n
- - I know what you&#x2019;re thinking (boring, or reminds you of project estimation)\n- simple enough that none of us really have to think about how it works\n- algorithmically complex enough that we might screw it up\n(and it takes more than one test to drive a full implementation)\n
- - not going to do a live coding demo\n(but hopefully appears on github and my blog soon)\n- create a new &#x201C;Single View Application&#x201D;, style up the NIB\n- design skills?\n(this is why I&#x2019;ve been asking questions about Interface Builder)\n\n
- - not going to do a live coding demo\n(but hopefully appears on github and my blog soon)\n- create a new &#x201C;Single View Application&#x201D;, style up the NIB\n- design skills?\n(this is why I&#x2019;ve been asking questions about Interface Builder)\n\n
- - not going to do a live coding demo\n(but hopefully appears on github and my blog soon)\n- create a new &#x201C;Single View Application&#x201D;, style up the NIB\n- design skills?\n(this is why I&#x2019;ve been asking questions about Interface Builder)\n\n
- - comes with unit tests by default\n- OCUnit is as easy as a check box, but other tools are easy too\n- used to be called SenTest or SenTestingKit, came bundled since Xcode 2\n- sets up applications tests / logic tests -> why?\n- application tests run in the context of your app (UI environment), can run on device)\n- Run with Cmd U -> shortcuts talk\n- but the example test fails\n
- - comes with unit tests by default\n- OCUnit is as easy as a check box, but other tools are easy too\n- used to be called SenTest or SenTestingKit, came bundled since Xcode 2\n- sets up applications tests / logic tests -> why?\n- application tests run in the context of your app (UI environment), can run on device)\n- Run with Cmd U -> shortcuts talk\n- but the example test fails\n
- - comes with unit tests by default\n- OCUnit is as easy as a check box, but other tools are easy too\n- used to be called SenTest or SenTestingKit, came bundled since Xcode 2\n- sets up applications tests / logic tests -> why?\n- application tests run in the context of your app (UI environment), can run on device)\n- Run with Cmd U -> shortcuts talk\n- but the example test fails\n
- - comes with unit tests by default\n- OCUnit is as easy as a check box, but other tools are easy too\n- used to be called SenTest or SenTestingKit, came bundled since Xcode 2\n- sets up applications tests / logic tests -> why?\n- application tests run in the context of your app (UI environment), can run on device)\n- Run with Cmd U -> shortcuts talk\n- but the example test fails\n
- - fail\n- imagine this is a build light\n- or one of those evil build bunnies\n\n
- - let&#x2019;s have a look at the example test file\n- SenTest is OCUnit, didn&#x2019;t both to rename everything (like NSObject from NextStep)\n- subclass SenTestCase (like JUnit 3 days)\n- test methods return void and take no arguments, dynamically detected\n- extract code into common setUp/tearDown\n- remember to add these classes to the test bundle only\n
- - let&#x2019;s have a look at the example test file\n- SenTest is OCUnit, didn&#x2019;t both to rename everything (like NSObject from NextStep)\n- subclass SenTestCase (like JUnit 3 days)\n- test methods return void and take no arguments, dynamically detected\n- extract code into common setUp/tearDown\n- remember to add these classes to the test bundle only\n
- - let&#x2019;s have a look at the example test file\n- SenTest is OCUnit, didn&#x2019;t both to rename everything (like NSObject from NextStep)\n- subclass SenTestCase (like JUnit 3 days)\n- test methods return void and take no arguments, dynamically detected\n- extract code into common setUp/tearDown\n- remember to add these classes to the test bundle only\n
- - let&#x2019;s have a look at the example test file\n- SenTest is OCUnit, didn&#x2019;t both to rename everything (like NSObject from NextStep)\n- subclass SenTestCase (like JUnit 3 days)\n- test methods return void and take no arguments, dynamically detected\n- extract code into common setUp/tearDown\n- remember to add these classes to the test bundle only\n
- - let&#x2019;s have a look at the example test file\n- SenTest is OCUnit, didn&#x2019;t both to rename everything (like NSObject from NextStep)\n- subclass SenTestCase (like JUnit 3 days)\n- test methods return void and take no arguments, dynamically detected\n- extract code into common setUp/tearDown\n- remember to add these classes to the test bundle only\n
- - let&#x2019;s have a look at the example test file\n- SenTest is OCUnit, didn&#x2019;t both to rename everything (like NSObject from NextStep)\n- subclass SenTestCase (like JUnit 3 days)\n- test methods return void and take no arguments, dynamically detected\n- extract code into common setUp/tearDown\n- remember to add these classes to the test bundle only\n
- - let&#x2019;s have a look at the example test file\n- SenTest is OCUnit, didn&#x2019;t both to rename everything (like NSObject from NextStep)\n- subclass SenTestCase (like JUnit 3 days)\n- test methods return void and take no arguments, dynamically detected\n- extract code into common setUp/tearDown\n- remember to add these classes to the test bundle only\n
- Controller Tests\n- 2 types: logic and IB plumbing\n- shouldn&#x2019;t be much logic anyway, but start here and extract as needed\n(for simple apps, maybe it&#x2019;s ok, but we&#x2019;ve all seen almost entire apps implemented in a couple of UIViewControllers)\n- can test IB plumbing if you really want (much longer than dragging connections, but if people don&#x2019;t look at their commits, can easily screw up and have pretty large effects)\n- large effect, should notice quickly, wont be a subtle bug\n
- - let&#x2019;s look at some example tests\n- long descriptive name, not camel case\n-- dual purpose (what&#x2019;s being done, should happen)\n- set up without the NIB, independent of IB (our environment)\n(talk about tests that do use the NIB later)\n- feed in our own label for testing against (could use mock/fake, but can use real)\n- call method and assert outcome\n\n
- - let&#x2019;s look at some example tests\n- long descriptive name, not camel case\n-- dual purpose (what&#x2019;s being done, should happen)\n- set up without the NIB, independent of IB (our environment)\n(talk about tests that do use the NIB later)\n- feed in our own label for testing against (could use mock/fake, but can use real)\n- call method and assert outcome\n\n
- - let&#x2019;s look at some example tests\n- long descriptive name, not camel case\n-- dual purpose (what&#x2019;s being done, should happen)\n- set up without the NIB, independent of IB (our environment)\n(talk about tests that do use the NIB later)\n- feed in our own label for testing against (could use mock/fake, but can use real)\n- call method and assert outcome\n\n
- - let&#x2019;s look at some example tests\n- long descriptive name, not camel case\n-- dual purpose (what&#x2019;s being done, should happen)\n- set up without the NIB, independent of IB (our environment)\n(talk about tests that do use the NIB later)\n- feed in our own label for testing against (could use mock/fake, but can use real)\n- call method and assert outcome\n\n
- - let&#x2019;s look at some example tests\n- long descriptive name, not camel case\n-- dual purpose (what&#x2019;s being done, should happen)\n- set up without the NIB, independent of IB (our environment)\n(talk about tests that do use the NIB later)\n- feed in our own label for testing against (could use mock/fake, but can use real)\n- call method and assert outcome\n\n
- - let&#x2019;s look at some example tests\n- long descriptive name, not camel case\n-- dual purpose (what&#x2019;s being done, should happen)\n- set up without the NIB, independent of IB (our environment)\n(talk about tests that do use the NIB later)\n- feed in our own label for testing against (could use mock/fake, but can use real)\n- call method and assert outcome\n\n
- - have a look at the code as a whole\n-> everything fails, doesn&#x2019;t even compile (a test doesn&#x2019;t have to fail to run)\n-> sometimes quicker to write interface/empty implementation first\n(get autocompletion)\n-> add label property and reset action (IBOutlet/IBAction or do this later)\n- should be enough to build and run\n- press Cmd U again and run your tests\n
- - that&#x2019;s fine, we haven&#x2019;t written the implementation yet\n- important to see your tests fail first, so you know they work\n
- - that&#x2019;s pretty simple\n- always a judgment call how simple is too simple\n- could introduce an ivar, convert to string\n(we know we&#x2019;ll need to set that current variable back to zero at some stage)\n
- - that&#x2019;s pretty simple\n- always a judgment call how simple is too simple\n- could introduce an ivar, convert to string\n(we know we&#x2019;ll need to set that current variable back to zero at some stage)\n
- - that&#x2019;s pretty simple\n- always a judgment call how simple is too simple\n- could introduce an ivar, convert to string\n(we know we&#x2019;ll need to set that current variable back to zero at some stage)\n
- - don&#x2019;t need more than that - if you&#x2019;re estimating\n- usually write one test at a time\n- if pair programming, ping pong between them\n-> tests are easy, move all the set up code to set up\njust call next 0, 1 or 2 times\n- next method won&#x2019;t exist, go and create it, empty implementation\n
- - don&#x2019;t need more than that - if you&#x2019;re estimating\n- usually write one test at a time\n- if pair programming, ping pong between them\n-> tests are easy, move all the set up code to set up\njust call next 0, 1 or 2 times\n- next method won&#x2019;t exist, go and create it, empty implementation\n
- - don&#x2019;t need more than that - if you&#x2019;re estimating\n- usually write one test at a time\n- if pair programming, ping pong between them\n-> tests are easy, move all the set up code to set up\njust call next 0, 1 or 2 times\n- next method won&#x2019;t exist, go and create it, empty implementation\n
- - don&#x2019;t need more than that - if you&#x2019;re estimating\n- usually write one test at a time\n- if pair programming, ping pong between them\n-> tests are easy, move all the set up code to set up\njust call next 0, 1 or 2 times\n- next method won&#x2019;t exist, go and create it, empty implementation\n
- - don&#x2019;t need more than that - if you&#x2019;re estimating\n- usually write one test at a time\n- if pair programming, ping pong between them\n-> tests are easy, move all the set up code to set up\njust call next 0, 1 or 2 times\n- next method won&#x2019;t exist, go and create it, empty implementation\n
- - don&#x2019;t need more than that - if you&#x2019;re estimating\n- usually write one test at a time\n- if pair programming, ping pong between them\n-> tests are easy, move all the set up code to set up\njust call next 0, 1 or 2 times\n- next method won&#x2019;t exist, go and create it, empty implementation\n
- - don&#x2019;t need more than that - if you&#x2019;re estimating\n- usually write one test at a time\n- if pair programming, ping pong between them\n-> tests are easy, move all the set up code to set up\njust call next 0, 1 or 2 times\n- next method won&#x2019;t exist, go and create it, empty implementation\n
- - don&#x2019;t need more than that - if you&#x2019;re estimating\n- usually write one test at a time\n- if pair programming, ping pong between them\n-> tests are easy, move all the set up code to set up\njust call next 0, 1 or 2 times\n- next method won&#x2019;t exist, go and create it, empty implementation\n
- - again, expect the test to fail\n- test failures are not always a bad thing\n
- - brown madza\n- simplest thing for now, we&#x2019;ll come back later\n
- - don&#x2019;t need more than that if you&#x2019;re estimating\n- usually write one test at a time\n- if pair programming, ping pong between them\n-> tests are easy, move all the set up code to set up\njust call next 0, 1 or 2 times\n- next method won&#x2019;t exist, go and create it, empty implementation\n- eventually, the algorithm will be complete no matter how far you count\n
- - once your tests are passing, always look to improve your code\n- step 3: refactor\n- you&#x2019;ll never do it later, do it now...\n(don&#x2019;t take on technical debt)\n- probably not as awesome as an old english sports car\n
- - once your tests are passing, always look to improve your code\n- step 3: refactor\n- you&#x2019;ll never do it later, do it now...\n(don&#x2019;t take on technical debt)\n- probably not as awesome as an old english sports car\n
- - once your tests are passing, always look to improve your code\n- step 3: refactor\n- you&#x2019;ll never do it later, do it now...\n(don&#x2019;t take on technical debt)\n- probably not as awesome as an old english sports car\n
- - once your tests are passing, always look to improve your code\n- step 3: refactor\n- you&#x2019;ll never do it later, do it now...\n(don&#x2019;t take on technical debt)\n- probably not as awesome as an old english sports car\n
- controller has two main methods, but don&#x2019;t really want all the algorithm code there\n- controllers get too busy, so separate out those details into a model\n- controller is left just plumbing things together, dealing with lifecycle\n- most iOS apps have almost the entire app written in UIViewController classes\n
- controller has two main methods, but don&#x2019;t really want all the algorithm code there\n- controllers get too busy, so separate out those details into a model\n- controller is left just plumbing things together, dealing with lifecycle\n- most iOS apps have almost the entire app written in UIViewController classes\n
- controller has two main methods, but don&#x2019;t really want all the algorithm code there\n- controllers get too busy, so separate out those details into a model\n- controller is left just plumbing things together, dealing with lifecycle\n- most iOS apps have almost the entire app written in UIViewController classes\n
- controller has two main methods, but don&#x2019;t really want all the algorithm code there\n- controllers get too busy, so separate out those details into a model\n- controller is left just plumbing things together, dealing with lifecycle\n- most iOS apps have almost the entire app written in UIViewController classes\n
- controller has two main methods, but don&#x2019;t really want all the algorithm code there\n- controllers get too busy, so separate out those details into a model\n- controller is left just plumbing things together, dealing with lifecycle\n- most iOS apps have almost the entire app written in UIViewController classes\n
- controller has two main methods, but don&#x2019;t really want all the algorithm code there\n- controllers get too busy, so separate out those details into a model\n- controller is left just plumbing things together, dealing with lifecycle\n- most iOS apps have almost the entire app written in UIViewController classes\n
- controller has two main methods, but don&#x2019;t really want all the algorithm code there\n- controllers get too busy, so separate out those details into a model\n- controller is left just plumbing things together, dealing with lifecycle\n- most iOS apps have almost the entire app written in UIViewController classes\n
- - Interface Builder plumbing\n
- - Interface Builder plumbing\n
- - they&#x2019;re written in Kiwi or OCUnit, but let&#x2019;s not call them unit tests\n- it&#x2019;s an interesting testing problem to try\n-> how good is it in practice?\n (everyone says no, but no one has tried it... the only team I know that tried it thinks they were the most valuable tests in the suite)\n- for an individual developer, or a team who actually reads git diffs before committing?\n
- - let&#x2019;s take a look at a few potential Interface Builder and NIB test\n- might want to check that you&#x2019;ve set all your outlets correctly\n
- - let&#x2019;s take a look at a few potential Interface Builder and NIB test\n- might want to check that you&#x2019;ve set all your outlets correctly\n
- - might want to check your actions are correct\n
- - might want to check your actions are correct\n
- - check that your view gets cleaned up on low memory conditions\n- this one is potentially valuable\n- something we often forget, or get wrong but don&#x2019;t often manually test\n-> could use screenshot based testing before and after as well\n
- - check that your view gets cleaned up on low memory conditions\n- this one is potentially valuable\n- something we often forget, or get wrong but don&#x2019;t often manually test\n-> could use screenshot based testing before and after as well\n
- - didn&#x2019;t get a really good chance to look at it yet\n- it&#x2019;s a wrapper around OCUnit, so it runs within Xcode\n- heavily uses macros and blocks to make your tests nicer\n- only been out a few months, but actively worked on\n
- - series of nested blocks to describe behaviour in certain context\n(in some ways it&#x2019;s a bunch of different works for a similar function)\n- installation: static library, or cocoapods... vendor?\n
- - series of nested blocks to describe behaviour in certain context\n- reads a lot more like plain English (but with ObjC syntax noise)\n\n
- - series of nested blocks to describe behaviour in certain context\n- reads a lot more like plain English (but with ObjC syntax noise)\n\n
- - series of nested blocks to describe behaviour in certain context\n- reads a lot more like plain English (but with ObjC syntax noise)\n\n
- - in some ways it&#x2019;s a bunch of different works for a similar function\n-> but these small changes actually change the way you think about your tests\n- Spec, not Test. &#x201C;it should&#x201D;, not &#x201C;testThat&#x201D;\n-> start describing the behaviour of your code, not testing the functionality\n- promotes test-first thinking\n
- - Kiwi comes with its own mocking/stubbing capability\n(nicer syntax than OCMock, haven&#x2019;t looked at LRMocky)\n
- - look at our refactored code\n- controller is just passing messages between views and models\n
- \n
- - command line tooling is always an afterthought with Apple tools\n(surprising, given the Unix history)\n- need command line for running in CI without human intervention\n
- xcodebuild -project FibCounter.xcodeproj -target FibCounterTests -configuration Debug -sdk iphonesimulator build\n
- - xcode build specifies workspaces and schemes as well\n- workspaces and schemes seem worthwhile\n- the build step will run your unit \n
- \n
- - training course is $70 or so, really worth while\n- Doug Sjoquist - idevblogaday, part 2 is out, more coming\n- Prag Prog had a few articles over the last year or two\n
- - training course is $70 or so, really worth while\n- Doug Sjoquist - idevblogaday, part 2 is out, more coming\n- Prag Prog had a few articles over the last year or two\n
- - training course is $70 or so, really worth while\n- Doug Sjoquist - idevblogaday, part 2 is out, more coming\n- Prag Prog had a few articles over the last year or two\n
- - training course is $70 or so, really worth while\n- Doug Sjoquist - idevblogaday, part 2 is out, more coming\n- Prag Prog had a few articles over the last year or two\n
- - training course is $70 or so, really worth while\n- Doug Sjoquist - idevblogaday, part 2 is out, more coming\n- Prag Prog had a few articles over the last year or two\n
- - training course is $70 or so, really worth while\n- Doug Sjoquist - idevblogaday, part 2 is out, more coming\n- Prag Prog had a few articles over the last year or two\n
- - training course is $70 or so, really worth while\n- Doug Sjoquist - idevblogaday, part 2 is out, more coming\n- Prag Prog had a few articles over the last year or two\n
- - training course is $70 or so, really worth while\n- Doug Sjoquist - idevblogaday, part 2 is out, more coming\n- Prag Prog had a few articles over the last year or two\n
- \n
- \n
- \n
- \n