No content

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 

Our Mission Advancing the Kotlin programming community in San Diego, and beyond. 

Raffle! $1 

A word from our sponsors... 

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

No content

No content

No content

Call for Presenters Get your 15, 30, 45+ minutes of fame by sharing your favorite Kotlin-related whatever! 

Call for Sponsors Get your name up in lights, and the eternal gratitude of San Diego’s Kotlin engineers! 

Announcements? ● Hiring? ● Looking for work? ● Other meetups? 

Dana Gibson ● Rocking his Kotlin shirt at the Neil Young concert 

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 

Try Kotlin Online https://try.kotlinlang.org/ 

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

TDD in Kotlin Ian Brandt 

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 

Test and Assertion Frameworks ● Mostly as in Java ○ JUnit ○ TestNG ○ AssertJ ○ Mockito 

Test and Assertion Frameworks ● Kotlin-specific frameworks evolving ○ Mockk ○ Atrium ○ KotlinTest ○ Spek ○ kotlin.test 

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) 

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 

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 

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 

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 

The Transformation Priority Premise ● Refactoring: Changing the structure of code without changing its behavior ● Transforming: Changing the behavior 

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 

Let’s code!