KotlinConf 2018 - Best Practices for Unit Testing in Kotlin by Philipp Hauer

Share
Embed
  • Published on Oct 14, 2018
  • Recording brought to you by American Express americanexpress.io/kotlin-jobs
    Unit Testing in Kotlin is fun and tricky at the same time. We can benefit a lot from Kotlin's powerful language features to write readable and concise unit tests. But in order to write idiomatic Kotlin test code in the first place, there is a certain test setup required. We'll talk about test lifecycles, mocking challenges, proper assertion libraries, the power of data classes and about spring integration. This talk contains best practices and guidelines to write unit test code in Kotlin that is idiomatic, readable, concise and produces reasonable failure messages.

    About the Presenter:
    Philipp Hauer works as a team lead for Spreadshirt in Leipzig, Germany. He focuses on developing JVM-based web applications and is enthusiastic about Kotlin, clean code, architectures and the sociology of software development. Moreover, Philipp is a keen blogger and tweets from time to time.
  • Science & TechnologyScience & Technology

Comments • 17

  • zhou7yuan
    zhou7yuan Year ago +15

    My First Test in Kotlin... [0:53]
    (Agenda) [2:17]
    Recap: Idiomatic Kotlin Code [2:34]
    Test Class Lifecycle [3:29]
    JUnit4: always new test class instances [3:34]
    JUnit4: static for the initial setup code [4:22]
    JUnit5 to the Rescue [5:34]
    JUnit5: Reuse the Test Class Instance [6:10]
    @TestInstance(TestInstance.Lifecycle.PER_CLASS)
    JUnit5: Change the Lifecycle Default [8:55]
    src/test/resources/junit-platform.properties:
    junit.jupiter.testinstance.lifecycle.default = per_class
    Test Names and Grouping [9:31]
    Backticks [9:36]
    @Nested Inner Classes [10:30]
    Kotlin Test Libraries [11:22]
    Being Spoilt for Choice [11:45]
    personal choice: JUnit5 + MockK + AssertJ
    Test-Specific Extension Functions [13:19]
    Mock Handling [14:46]
    Classes Are Final by Default [14:50]
    Solutions: Interfaces / open explicitly / Mockito: incubating feature / MockK
    MockK [15:50]
    Does Test Speed Matter? [18:38]
    Don't Recreate Mocks [19:10]
    Create Mocks Once, Reset Them [19:36]
    init() { clearMocks(repo, client) }
    Handle Classes with State [20:28]
    Spring Integration [21:31]
    All-Open Compiler Plugin [22:52]
    `org.jetbrains.kotlin:kotlin-maven-allopen:${kotlin.version}`
    spring
    Constructor Injection for Spring-free Testing [23:17]
    Utilize Data Classes [24:30]
    Data Classes for Assertions [24:35]
    self-explanatory [26:07]
    Helper Function for Object Creation [28:38]
    Data Classes for Parameterized Tests [31:47]
    Conclusion [33:55]
    Best Practices for Testing in Kotlin [34:24]

  • Ryan M. Kay - wiseAss
    Ryan M. Kay - wiseAss 3 years ago +6

    Vielen dank Philipp! I was live streaming about TDD and writing tests for suspending functions this morning, but I've already seen a number of things I can improve. I didn't even know about JUnit 5 lol...

    In any case, I'm glad to say that Unit Testing in Kotlin is now officially as easy as my mature set up with Java used to be. Definitely some hiccups to get set up, but as long as I can Test coroutines, I'll be a happy coder.

    If anyone's curious about writing tests for coroutines and TDD in general, consider checking this out:
    thexvid.com/video/MZIFSrETRek/video.html

    • Massenhaft1
      Massenhaft1 3 years ago

      Maybe you should try spek2...its also nice :)

  • Nick Apperley
    Nick Apperley 3 years ago

    When it comes to assertions with Kotlin Test (the Kotlin community one, not the JB one) it includes its own which are built in ( github.com/kotlintest/kotlintest/blob/master/doc/reference.md#matchers-and-assertions ). This removes the need to choose a Assertion library and also makes deployment simpler.

  • Wavesonics
    Wavesonics 3 years ago +1

    Great talk, really helpful

  • Makoto the Witch
    Makoto the Witch Year ago

    21:20 could you not simply use a custom getter to create a factory? you would have to obtain an instance in your test method, but that would always be reset

  • Torsten Werner
    Torsten Werner 2 years ago +1

    an important topic nicely presented

  • Martin Vyšný
    Martin Vyšný 3 years ago

    A good talk! But the problem is that you're converting traditional Java approach 1:1 into Kotlin, instead of rethinking the whole testing problem in Kotlin terms. If you use annotations, then instead in Java you program in a mini-language interpreted in runtime by magic (aka annotating test stuff). Please check here for a truly Kotlin approach: github.com/mvysny/dynatest

  • k y
    k y 2 years ago +2

    Unrelated, but I love the intro. It has to be only intro I wish that was longer.

  • Mercy
    Mercy 2 years ago +3

    Why junit5 is not default on gradle?

  • Just The Highlights
    Just The Highlights 2 years ago

    35:36 - phauer.com/2018/best-practices-unit-testing-kotlin/

    2019 blog - phauer.com/2019/modern-best-practices-testing-java/

  • Nilesh Miskin
    Nilesh Miskin 2 years ago

    Long way to go! That's why Spock really shines!

  • 70ME3E
    70ME3E 2 years ago +1

    gr8 stuff!

  • bioman
    bioman Year ago

    Unfortunatelly I can't give you a thumbs up as I still don't know how to setup a project so that i can run tests :-\

  • Paul-Sebastian Manole
    Paul-Sebastian Manole 3 years ago

    Too few words...

  • Bart Houkes
    Bart Houkes 5 months ago

    Jetbranins is making the world very complicated. This is a lot of bool. The title is misleading, just to attract designers to this boring lecture, not about testing.

    • JetBrainsTV
      JetBrainsTV  4 months ago

      To be clear, this was a community talk from KotlinConf 2018.