Intro and Presentation - TDD in Kotlin by Ian Brandt

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

Transcript

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/
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!