Wrote a quick blog on avoiding mocks by using Test...

# kotest

[sam]

Wrote a quick blog on avoiding mocks by using Test Containers and Kotest https://medium.com/@sam_57450/unitigration-testing-with-kotest-and-test-containers-55b7ad28f615

[thanksforallthefish]

very nice, though the obvious question then becomes: how do you scale up? meaning, how do you avoid mocks (and stubs) in the application service using the repository?

class UserApplicationService(
  val dataStore: UserDataStore,
  val validator: Validator
) {
  fun create(userDetails: UserDetails) {
    val user = convert(userDetails)
    validator.throwWhenInvalid(user)
    dataStore.insert(user)
  }

  private fun convert(userDetails: UserDetails) = ....
}

you can ofc inject the “real” dataStore (ie: backed by test container), but at that point as soon as you application grows duration of these unitigration (nice term btw) becomes unbearable, especially for local development (I guess in CI you can smart starters that starts all needed container once before)

my team actually uses a similar approach, we start a small spring context for testing repositories and we run testcontainer for those, but we still need mocks when it comes to business logic tests

[thanksforallthefish]

mocks could be replaced by stubs, but I don’t see the point, stubs (for me) are just global mocks, ie: you have a simplified fixed implementation that you share between all tests that uses that component, which imo is more work than just mocking when needed

[Rob Elliot]

I've worked on projects which were almost entirely tested using an http client - so the real app & db are run up for all the tests.

[Rob Elliot]

Nowadays I prefer to write contract tests for the interfaces that do I/O and then write an in-memory implementation alongside the real db implementation. Then the contract tests give me confidence that tests I write against the full stack with stubs are valid.

[thanksforallthefish]

I never considered contract testing for in-app testing. interesting. at first glance seems to me another level of stubbing, and given I have my unitigration tests for repositories/other services, it feels mocking would be simpler and giving same confidence level.

but I’ll try next time I have to start a module/new service