(Unit) Testing iOS Apps

(Unit) Testing iOS Apps

15633e65c96546d830fb84ee7fe5db9c?s=128

Pawel Dudek

January 24, 2014
Tweet

Transcript

  1. (Unit) Testing iOS Apps Paweł Dudek

  2. So a QA guys walks into your room…

  3. That’s a lot of wasted time.

  4. Could it be saved?

  5. YES!!! If only we had a better test coverage...

  6. One of the many reasons why you want to have

    tests. What are the others?
  7. Reasons for testing • Saved time • Better codebase •

    Faster development cycles • Being “confident” about your code • More saved time
  8. More saved time? What?

  9. Common misconceptions

  10. Common misconceptions • “It will take longer to write code”

    or “Time spent writing/refactoring tests is time lost” • “It will take more time to modify existing system”
  11. Am I going to write poor software if I don’t

    do tests?
  12. 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
  13. Now that we know that writing tests is a good

    idea...
  14. How can we do it?

  15. • You will feel confused • You won’t know how

    to start • You will need help • Conclusion: it’s not easy to start
  16. Tips • Never think of tests as tests • Think

    of a scenario, behavior, example • Grab a mature project from github with tests included • Find someone experienced and ask questions • Program in pairs!
  17. Get on with it! How can we test?

  18. Working effectively with legacy code Michael C. Feathers

  19. TDD • Test Driven Development • Red, Green, Refactor •

    Write failing test first • Fix it • Refactor
  20. BDD Behavior Driven Development

  21. How does BDD differ from TDD?

  22. BDD builds upon TDD by formalising the good habits of

    the best TDD practitioners. Matt Wynne, XP Evangelist
  23. Good habits

  24. Unit Tests

  25. OCUnit

  26. OCUnit Syntax • All test classes inherit from SenTestCase •

    All tests begin with test • Setup and teardown method • Everything else is ignored by testing framework • Means you can use as additional setup methods!
  27. -(void)testFullName { Person *person = [Person person]; person.firstName = @"Mariusz";

    person.secondName = @"Testowniczek"; NSString *fullName = [person fullName]; NSString *expectedName = @"Mariusz Testowniczek"; STAssertTrue([fullName isEqualToString:expectedName], @""); }
  28. OCUnit vs XCTest

  29. OCUnit vs XCTest

  30. Behavior Tests

  31. Kiwi and Cedar

  32. None
  33. SPEC_BEGIN(PersonSpec) ! describe(@"Person", ^{ __block Person *person; ! beforeEach(^{ person

    = [[Person alloc] init]; person.firstName = @"Mariusz"; person.lastName = @"Fixture Last Name"; }); ! describe(@"full name", ^{ ! __block NSString *fullName; ! beforeEach(^{ fullName = [person fullName]; }); ! it(@"should return the full name", ^{ expect(fullName).to(equal(@"Mariusz Testowniczek")); }); }); }); ! SPEC_END
  34. iOS Testing Tips

  35. Testing UI Layout

  36. System Singletons

  37. Common caveats

  38. Example

  39. More advanced topics

  40. Summary

  41. Summary • Testing is a great way to help developers

    • Better codebase, faster iterations • Invaluable for larger projects
  42. Resources & Contact @eldudi github.com/paweldudek pawel@dudek.mobi Code Examples Contact