iOS Unit Testing

Editor's Notes

• #2: \n
• #3: - what is unit testing\n- introduction to ocunit in general\n
• #4: - what is unit testing\n- introduction to ocunit in general\n
• #5: - what is unit testing\n- introduction to ocunit in general\n
• #6: - what is unit testing\n- introduction to ocunit in general\n
• #7: - Frank talk at the first cocoaheads of the year in February\n- thanks to Oliver for editing and uploading video\n
• #8: - balance your tests (Kevin doesn’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’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’s not call them unit tests)\n- xUnit v RSpec style tests\n
• #9: - balance your tests (Kevin doesn’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’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’s not call them unit tests)\n- xUnit v RSpec style tests\n
• #10: - balance your tests (Kevin doesn’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’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’s not call them unit tests)\n- xUnit v RSpec style tests\n
• #11: - balance your tests (Kevin doesn’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’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’s not call them unit tests)\n- xUnit v RSpec style tests\n
• #12: - balance your tests (Kevin doesn’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’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’s not call them unit tests)\n- xUnit v RSpec style tests\n
• #13: - balance your tests (Kevin doesn’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’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’s not call them unit tests)\n- xUnit v RSpec style tests\n
• #14: - balance your tests (Kevin doesn’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’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’s not call them unit tests)\n- xUnit v RSpec style tests\n
• #15: - balance your tests (Kevin doesn’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’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’s not call them unit tests)\n- xUnit v RSpec style tests\n
• #16: - this is partly true, but it’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
• #17: - fallacy of unit testing is that it’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’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
• #18: - entire unit test suite should take seconds to run\n- if you can’t hold your breath while your test suite runs, don’t hold your breath that anyone will run it\n- specific errors, right after they occur\n- in context\n
• #19: - see them fail first: it is possible to have bugs in your tests\n- get them passing, only what’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’s an idiot\n
• #20: \n
• #21: - 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
• #22: - 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
• #23: - 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
• #24: - that’s US dollars\n- I don’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’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’re comfortable with working in this way, I find it quicker than not writing tests\n
• #25: - that’s US dollars\n- I don’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’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’re comfortable with working in this way, I find it quicker than not writing tests\n
• #26: - that’s US dollars\n- I don’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’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’re comfortable with working in this way, I find it quicker than not writing tests\n
• #27: - testing is ultimately about pragmatism\n- plenty of good programmers don’t TDD, I’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’s up to you\n
• #28: - testing is ultimately about pragmatism\n- plenty of good programmers don’t TDD, I’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’s up to you\n
• #29: - testing is ultimately about pragmatism\n- plenty of good programmers don’t TDD, I’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’s up to you\n
• #30: - I know what you’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
• #31: - I know what you’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
• #32: - I know what you’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
• #33: - not going to do a live coding demo\n(but hopefully appears on github and my blog soon)\n- create a new “Single View Application”, style up the NIB\n- design skills?\n(this is why I’ve been asking questions about Interface Builder)\n\n
• #34: - not going to do a live coding demo\n(but hopefully appears on github and my blog soon)\n- create a new “Single View Application”, style up the NIB\n- design skills?\n(this is why I’ve been asking questions about Interface Builder)\n\n
• #35: - not going to do a live coding demo\n(but hopefully appears on github and my blog soon)\n- create a new “Single View Application”, style up the NIB\n- design skills?\n(this is why I’ve been asking questions about Interface Builder)\n\n
• #36: - 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
• #37: - 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
• #38: - 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
• #39: - 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
• #40: - fail\n- imagine this is a build light\n- or one of those evil build bunnies\n\n
• #41: - let’s have a look at the example test file\n- SenTest is OCUnit, didn’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
• #42: - let’s have a look at the example test file\n- SenTest is OCUnit, didn’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
• #43: - let’s have a look at the example test file\n- SenTest is OCUnit, didn’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
• #44: - let’s have a look at the example test file\n- SenTest is OCUnit, didn’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
• #45: - let’s have a look at the example test file\n- SenTest is OCUnit, didn’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
• #46: - let’s have a look at the example test file\n- SenTest is OCUnit, didn’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
• #47: - let’s have a look at the example test file\n- SenTest is OCUnit, didn’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
• #48: Controller Tests\n- 2 types: logic and IB plumbing\n- shouldn’t be much logic anyway, but start here and extract as needed\n(for simple apps, maybe it’s ok, but we’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’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
• #49: - let’s look at some example tests\n- long descriptive name, not camel case\n-- dual purpose (what’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
• #50: - let’s look at some example tests\n- long descriptive name, not camel case\n-- dual purpose (what’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
• #51: - let’s look at some example tests\n- long descriptive name, not camel case\n-- dual purpose (what’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
• #52: - let’s look at some example tests\n- long descriptive name, not camel case\n-- dual purpose (what’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
• #53: - let’s look at some example tests\n- long descriptive name, not camel case\n-- dual purpose (what’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
• #54: - let’s look at some example tests\n- long descriptive name, not camel case\n-- dual purpose (what’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
• #55: - have a look at the code as a whole\n-> everything fails, doesn’t even compile (a test doesn’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
• #56: - that’s fine, we haven’t written the implementation yet\n- important to see your tests fail first, so you know they work\n
• #57: - that’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’ll need to set that current variable back to zero at some stage)\n
• #58: - that’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’ll need to set that current variable back to zero at some stage)\n
• #59: - that’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’ll need to set that current variable back to zero at some stage)\n
• #60: - don’t need more than that - if you’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’t exist, go and create it, empty implementation\n
• #61: - don’t need more than that - if you’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’t exist, go and create it, empty implementation\n
• #62: - don’t need more than that - if you’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’t exist, go and create it, empty implementation\n
• #63: - don’t need more than that - if you’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’t exist, go and create it, empty implementation\n
• #64: - don’t need more than that - if you’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’t exist, go and create it, empty implementation\n
• #65: - don’t need more than that - if you’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’t exist, go and create it, empty implementation\n
• #66: - don’t need more than that - if you’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’t exist, go and create it, empty implementation\n
• #67: - don’t need more than that - if you’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’t exist, go and create it, empty implementation\n
• #68: - again, expect the test to fail\n- test failures are not always a bad thing\n
• #69: - brown madza\n- simplest thing for now, we’ll come back later\n
• #70: - don’t need more than that if you’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’t exist, go and create it, empty implementation\n- eventually, the algorithm will be complete no matter how far you count\n
• #71: - once your tests are passing, always look to improve your code\n- step 3: refactor\n- you’ll never do it later, do it now...\n(don’t take on technical debt)\n- probably not as awesome as an old english sports car\n
• #72: - once your tests are passing, always look to improve your code\n- step 3: refactor\n- you’ll never do it later, do it now...\n(don’t take on technical debt)\n- probably not as awesome as an old english sports car\n
• #73: - once your tests are passing, always look to improve your code\n- step 3: refactor\n- you’ll never do it later, do it now...\n(don’t take on technical debt)\n- probably not as awesome as an old english sports car\n
• #74: - once your tests are passing, always look to improve your code\n- step 3: refactor\n- you’ll never do it later, do it now...\n(don’t take on technical debt)\n- probably not as awesome as an old english sports car\n
• #75: controller has two main methods, but don’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
• #76: controller has two main methods, but don’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
• #77: controller has two main methods, but don’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
• #78: controller has two main methods, but don’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
• #79: controller has two main methods, but don’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
• #80: controller has two main methods, but don’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
• #81: controller has two main methods, but don’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
• #82: - Interface Builder plumbing\n
• #83: - Interface Builder plumbing\n
• #84: - they’re written in Kiwi or OCUnit, but let’s not call them unit tests\n- it’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
• #85: - let’s take a look at a few potential Interface Builder and NIB test\n- might want to check that you’ve set all your outlets correctly\n
• #86: - let’s take a look at a few potential Interface Builder and NIB test\n- might want to check that you’ve set all your outlets correctly\n
• #87: - might want to check your actions are correct\n
• #88: - might want to check your actions are correct\n
• #89: - 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’t often manually test\n-> could use screenshot based testing before and after as well\n
• #90: - 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’t often manually test\n-> could use screenshot based testing before and after as well\n
• #91: - didn’t get a really good chance to look at it yet\n- it’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
• #92: - series of nested blocks to describe behaviour in certain context\n(in some ways it’s a bunch of different works for a similar function)\n- installation: static library, or cocoapods... vendor?\n
• #93: - 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
• #94: - 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
• #95: - 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
• #96: - in some ways it’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. “it should”, not “testThat”\n-> start describing the behaviour of your code, not testing the functionality\n- promotes test-first thinking\n
• #97: - Kiwi comes with its own mocking/stubbing capability\n(nicer syntax than OCMock, haven’t looked at LRMocky)\n
• #98: - look at our refactored code\n- controller is just passing messages between views and models\n
• #99: \n
• #100: - 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
• #101: xcodebuild -project FibCounter.xcodeproj -target FibCounterTests -configuration Debug -sdk iphonesimulator build\n
• #102: - xcode build specifies workspaces and schemes as well\n- workspaces and schemes seem worthwhile\n- the build step will run your unit \n
• #103: \n
• #104: - 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
• #105: - 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
• #106: - 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
• #107: - 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
• #108: - 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
• #109: - 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
• #110: - 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
• #111: - 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
• #112: \n
• #113: \n
• #114: \n
• #115: \n