Spring Boot with Kotlin & JUnit 5 - Tutorial 12 - Testing Best Practices

# Testing Best Practices - F.I.R.S.T Principles for Unit and Integration Tests in JUnit 5
Software testing is an art in itself. It’s easy to write down a bunch of test cases, but it’s hard to clean test cases that also perform adequate checks, have no redundancy, are performant, independent of each other, and so on.
The F.I.R.S.T. principles for automated tests are a great guide to follow when it comes to implement test cases, whether in JUnit 5, TestNG, or some other tool. The acronym F.I.R.S.T. stands for: FAST, ISOLATED, REPEATABLE, SELF-VALIDATING, TIMELY.

# Social

# GitHub Repository for This Tutorial Series

# Learn Kotlin
Kotlin Masterclass: planned
JUnit 5 Bootcamp: planned
☝️ Please sign up for early bird access above to be notified as soon as they launch!

# Check out Peter’s Udemy Courses

[georgeti]

Thank you very much for taking the time and sharing your knowledge with the world through these excellent tutorials!

[PeterSommerhoff]

Hope you enjoy this more conceptual type of tutorial as well!

Anyone else here actually enjoy writing tests or is it just me? 😆 How do you make sure your tests stay maintainable and clean?

[NightTerror]

I can't believe you still upload you taught me how to code java you are a legend

[SkipperChuck]

So I guess I should have watched this video before commenting on the last one ... the location of the delete test :) that is exactly what I ran into because I have the habit of putting all of my classes/methods/variables in alphabetical order. Got a little ahead of you, I guess. :)

[tmjromao]

Excellent! learned a lot, thanks for creating and sharing the tutorials. Wonder if you could you do a tutorial about serving html pages, static and dynamic. Routing and testing

[drbaz]

Enjoy writing tests? I enjoy writing successful tests ... 👀 Thanks, Peter, for your diligence in passing on your knowledge. Looking forward to more tutorials.

[abhisheksaxena]

Hey,
I noticed the issue with the isolation of the tests in the beginning, instead of having a mock class, you can mock the using mockk<KClass>() and define the behaviour within the test using every { situation/function call } returns/throws expected output to isolate them without creating a mock implementation. It is similar to Mickito's when().thenReturns implementation.
I think that's the more appropriate way to do. The same thing goes for service and repository tests.

[AnaitiArauz]

Who ever this is you are wonderful thanks for the great explanation! but out of curiosity...is Bucky not doing videos anymore?

[sumanbandopadhyay]

How do you suggest to test controllers when repositories are connected to database..?