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

Intro and Presentation - TDD in Kotlin by Ian Brandt

SD Kotlin
August 01, 2018

Intro and Presentation - TDD in Kotlin by Ian Brandt

Intro and presentation slides for SD Kotlin's August 2018 meeting.

SD Kotlin

August 01, 2018

More Decks by SD Kotlin

Other Decks in Programming


  1. None
  2. San Diego Kotlin User Group www.meetup.com/sd-kotlin www.linkedin.com/company/sd-kotlin github.com/sdkotlin @sdkotlin on

    Twitter, Facebook, and Instagram #san-diego on kotlinlang.slack.com
  3. Our Mission Advancing the Kotlin programming community in San Diego,

    and beyond.
  4. Raffle! $1

  5. A word from our sponsors...

  6. Forging STEM pioneers https://www.brandt.academy/

  7. None
  8. None
  9. None
  10. Call for Presenters Get your 15, 30, 45+ minutes of

    fame by sharing your favorite Kotlin-related whatever!
  11. Call for Sponsors Get your name up in lights, and

    the eternal gratitude of San Diego’s Kotlin engineers!
  12. Announcements? • Hiring? • Looking for work? • Other meetups?

  13. Dana Gibson • Rocking his Kotlin shirt at the Neil

    Young concert
  14. Kotlin News • Kotlin 1.3 M1! ◦ Coroutines graduating to

    stable ◦ Assignment of when subject to variable ◦ Unsigned integer types and arithmetic ◦ Function types with 255 parameters ◦ Multiplatform Random API ◦ Companion object for Boolean
  15. Try Kotlin Online https://try.kotlinlang.org/

  16. Let’s slack off! http://slack.kotlinlang.org/ #san-diego

  17. TDD in Kotlin Ian Brandt

  18. A Set of Unit Test Rules A test is not

    a unit test if: • It talks to the database • It communicates across the network • It touches the file system • It can't run at the same time as any of your other unit tests • You have to do special things to your environment (such as editing config files) to run it
  19. Test and Assertion Frameworks • Mostly as in Java ◦

    JUnit ◦ TestNG ◦ AssertJ ◦ Mockito
  20. Test and Assertion Frameworks • Kotlin-specific frameworks evolving ◦ Mockk

    ◦ Atrium ◦ KotlinTest ◦ Spek ◦ kotlin.test
  21. The Cycles of TDD • The Three Laws of TDD

    (seconds) • The Red-Green-Refactor Cycle (minutes) • The Specific/Generic Cycle (deca-minutes) • The Architectural Boundaries Cycle (hours)
  22. The Three Laws of TDD Second-by-Second • Thou shalt not

    write any production code without first writing a failing unit test • Thou shalt not write any more of a unit test than is necessary to fail (and not compiling is failing) • Thou shalt not write any more production code than is needed to make the most recent failing unit test pass
  23. The Red-Green-Refactor Cycle Minute-by-Minute • Get RED ◦ Just focus

    on the next test. • Get GREEN ◦ Just focus on the simplest way to make that test pass. Don’t worry about refactoring! • Now REFACTOR ◦ Keep the same tests passing
  24. The Specific/Generic Cycle ~Ten Minutes • As the tests get

    more specific, the code gets more generic ◦ I.e. if your next test drives the code to be more specific, maybe you picked the wrong next test ◦ You’ll know if you get stuck
  25. The Architecture Boundaries Cycle Hour-by-Hour • Pause to consider whether

    you’re evolving clean architecture ◦ Are you Red-Green-Refactoring your way to a monolith? • Refactor as needed with your awesome suite of super-fast unit tests
  26. The Transformation Priority Premise • Refactoring: Changing the structure of

    code without changing its behavior • Transforming: Changing the behavior
  27. The Transformation Priority Premise 1. ({} → nil) no code

    at all → code that employs nil 2. (nil → constant) 3. (constant → constant+) a simple constant to a more complex constant 4. (constant → scalar) replacing a constant with a variable or an argument 5. (statement → statements) adding more unconditional statements. 6. (unconditional → if) splitting the execution path 7. (scalar → array) 8. (array → container) 9. (statement → tail-recursion) 10. (if → while) 11. (statement → non-tail-recursion) 12. (expression → function) replacing an expression with a function or algorithm 13. (variable → assignment) replacing the value of a variable. 14. (case) adding a case (or else) to an existing switch or if
  28. Let’s code!