Upgrade to Pro — share decks privately, control downloads, hide ads and more …

TDD Workshop - UIKonf 2016

TDD Workshop - UIKonf 2016

15633e65c96546d830fb84ee7fe5db9c?s=128

Pawel Dudek

May 25, 2016
Tweet

Transcript

  1. Test Driven Development

  2. Why do we need tests?

  3. Preserving behaviors

  4. We're just humans

  5. Failsafe

  6. Test Driven Development

  7. Tests drive the way you code

  8. Always write test first

  9. Tests influence architecture of your app

  10. Tests tell you whether your design became too complex

  11. Have to simulate behavior of your dependency dependency dependency?

  12. Need to fake seven objects?

  13. Need to call five functions to simulate a behavior?

  14. Hard to specify clear requirements?

  15. Overcomplicated design

  16. Thinked-through design

  17. First consumer of your API

  18. Programs must be written for people to read, and only

    incidentally for machines to execute. — Harold Abelson
  19. There is no such thing as untestable behavior Only untestable

    code
  20. What is testable code?

  21. Good Architecture == Testable code

  22. What is good architecture?

  23. Cohesion

  24. Coupling

  25. Good design A simple definition

  26. High cohesion and low coupling

  27. Easily composable and context independent

  28. Good architecture - base rules » Single responsibility » Few

    dependencies » Depend on interfaces, not classes (yay POP!)
  29. None
  30. !!!

  31. http://www.martinfowler.com/ bliki/ DesignStaminaHypothesis.html

  32. SOLID

  33. SOLID Homework » Goruco 2009 - SOLID Object-Oriented Design -

    Sandi Metz » MCE^3 - Software Paradigms & Patterns — Did We Get It All Wrong? - Jon Reid » MCE^3 - Jorge Ortiz » Clean Architecture - Uncle Bob
  34. What is BDD

  35. Behavior Driven Development Test Driven Development

  36. What's the difference?

  37. BDD aims to improve certain aspect of TDD

  38. BDD tries to help you know what to test

  39. When writing tests don’t think ‘tests’

  40. Think about ‘behaviors’

  41. Think about examples how your object should behave

  42. An objects behavior is defined by methods it declares in

    its interface
  43. You should not be testing internal implementation of your object

    Only its interface
  44. Work outside-in

  45. Ubiquitous language

  46. Quick & Nimble

  47. class DolphinSpec: QuickSpec { override func spec() { it("is friendly")

    { expect(Dolphin().isFriendly).to(beTruthy()) } it("is smart") { expect(Dolphin().isSmart).to(beTruthy()) } } }
  48. describe("a dolphin") { describe("its click") { it("is loud") { let

    click = Dolphin().click() expect(click.isLoud).to(beTruthy()) } it("has a high frequency") { let click = Dolphin().click() expect(click.hasHighFrequency).to(beTruthy()) } } }
  49. describe("a dolphin") { var dolphin: Dolphin! beforeEach { dolphin =

    Dolphin() } describe("its click") { var click: Click! beforeEach { click = dolphin.click() } it("is loud") { expect(click.isLoud).to(beTruthy()) } it("has a high frequency") { expect(click.hasHighFrequency).to(beTruthy()) } } }
  50. describe("its click") { context("when the dolphin is not near anything

    interesting") { it("is only emitted once") { expect(dolphin!.click().count).to(equal(1)) } } context("when the dolphin is near something interesting") { beforeEach { let ship = SunkenShip() Jamaica.dolphinCove.add(ship) Jamaica.dolphinCove.add(dolphin) } it("is emitted three times") { expect(dolphin.click().count).to(equal(3)) } } }
  51. That's about it! Let's dive into code!

  52. Assignment 0 » Add data parsing in ChatMessagesUpdater

  53. Assignment 1 » Pass data from model object to table

    view cell
  54. That's all folks!