Skip to content
0:00 / 0:00

#junit#contracttesting#kotlin

How to Test Shared Behaviour with JUnit Contracts

Pairing with Duncan

4.5K subscribers • 16 videos on Hallway

YouTube
  • Recommended by 2 people: 2 in engineering communities.
  • Presented by Duncan McGregor, software developer
  • Linked in the descriptiondmcg/gilded-rose-tdd

Intermediate. Assumes working knowledge.

438 views4 years ago2 recommendations

Tools and practiceProgramming languagesTestingKotlinJava and the JVM

Duncan McGregor demonstrates how to use JUnit contract tests in Kotlin to ensure that test doubles and real implementations behave identically.

Now that we have created a fake implementation of the external ValueElf service, to stand in for the real thing in our tests, it would be nice to know that they behave the same way. We can increase our confidence by running the same tests against the test double and the real article. So we extract an abstract class with the tests, with setup delegated to concrete subclasses, one for the real implementation and one for our fake. I used to call the superclass AbstractFooTest, but as usual, cleverer people learned me to use more simple words - in England we say FooContract. This is Part 44 of an exploration of where a Test Driven Development implementation of the Gilded Rose stock control system might take us in Kotlin. You can see the whole series as a playlist youtube.com/playlist?list=PL1ssMPpyqociJNwykAOB9_KEZVW7BW7m2 and the code on GitHub github.com/dmcg/gilded-rose-tdd If you like this, you’ll probably like the book Java to Kotlin, A Refactoring Guidebook java-to-kotlin.dev.

Why it's here

2 people recommend this

What people say. Recommended as a guide to implementing contract testing for complex database or external service behaviors.

u/dmcgin r/Kotlin • Recommends

How to Test Shared Behaviour with JUnit Contracts

u/spatchcoqin r/ExperiencedDevs • Recommends

On “How to unit test when you have complex database behaviour?”

Have a look at contract testing ( link to this video In your situation we have a FooContract which is an interface (usually, in Kotlin) that has all the test methods and identifies the necessary actors, to be implemented by the concrete classes. FooDatabaseTest uses a real database. We run these in our integration suite . FooInMemoryTest... some people prefer the naming FooFakeTest, uses a fake version of the db that has been verified to mimic the real one, and can be run quickly as a unit test. One leans on the other in ways better explained by Duncan in the video above.