Given When Then - Refactoring to a Kotlin DSL

Software projects work better when the development team and business stakeholders agree on the behaviour of the system that they are building. Tests are a good way to share this specification, but only if all parties can understand them.

The Given When Then syntax of Cucumber tests is designed to be readable by normal people and interpreted by programmers. That interpretation by programmers is tedious though, so today we will look refactoring some Kotlin tests into a simple Given When Then domain specific language.

In this episode, I discuss the importance of aligning development teams and business stakeholders on software behavior using tests. I introduce the Given-When-Then syntax of Cucumber tests and show how to refactor Kotlin tests into a readable and simple domain-specific language (DSL). Watch as I dive into test scenarios, address common issues, and refactor code to achieve self-documenting and business-friendly tests, ensuring everyone can understand and agree on the system's behavior.

00:00:31 Look at our current tests
00:01:01 How to sense that things are not being saved?
00:02:47 IntelliJ import bug
00:04:14 Never trust a test you haven't seen fail
00:04:57 Now What about Given When Then
00:05:34 Given is the identity function on the initial test state
00:06:11 When and Then are let
00:07:30 IntelliJ crash
00:08:33 Use our Given When Then in another test
00:09:36 When is setup a Given not a When?
00:11:36 Make a Fixture for more complicated Givens
00:13:01 Some final readability improvements
00:16:20 Is this readable by our stakeholders?

There is a playlist of TDD Gilded Rose episodes -    • Test Driven Gilded Rose in Kotlin  

I get lots of questions about the test progress bar. It was written by the inimitable @dmitrykandalov. To use it install his Liveplugin (https://plugins.jetbrains.com/plugin/...) and then this gist https://gist.github.com/dmcg/1f56ac39...

If you like this video, you’ll probably like my book - Java to Kotlin, A Refactoring Guidebook (http://java-to-kotlin.dev). It's about far more than just the syntax differences between the languages - it shows how to upgrade your thinking to a more functional style.