Just change your image for the testcontainer creation to match the image in the docker compose file, that fixes your problems with timezones. I guess in the alpine image there is no timezone information installed to keep it as slim as possible.
I still have to watch the whole video but does duncan migrations run for each test? I have a weird combination that i want a clean db but with the migrations already ran, yet i don't know if it is related with Kotest or my testcontainer config
Unless you’re using kotest magic, you are in control of when containers are started, and when migrations are run. I guess a few println’s might clarify the lifecycle
Instead of a Postgres image based on Alpine Linux, you might want to try an image based on a more complete Linux variant, such as Debian. That might solve your supported timezones issue.
Another way to start the container once before all test cases is to let testcontainers control the lifecycle by using the Container annotation, but define the container in a companion object. It’s unlikely to Chang a much for you though. Example: ``` @Testcontainers(disabledWithoutDocker = true) class EventStoreDbExamples : EventStoreContract(EventStoreDbEventStore(eventStoreDb.connectionString)) { companion object { @Container private val eventStoreDb: EventStoreDbContainer = EventStoreDbContainer() } } ```
You don't really need to initialize the container yourself... the tc driver will do it for you, in the docs it shows what connection string you can use that postgres will be started for you. The only thing is that there are less configuration options in that case.
Just change your image for the testcontainer creation to match the image in the docker compose file, that fixes your problems with timezones. I guess in the alpine image there is no timezone information installed to keep it as slim as possible.
Strangely I didn’t even think that I had a working container downloaded that I could use!
I still have to watch the whole video but does duncan migrations run for each test? I have a weird combination that i want a clean db but with the migrations already ran, yet i don't know if it is related with Kotest or my testcontainer config
Unless you’re using kotest magic, you are in control of when containers are started, and when migrations are run. I guess a few println’s might clarify the lifecycle
Instead of a Postgres image based on Alpine Linux, you might want to try an image based on a more complete Linux variant, such as Debian. That might solve your supported timezones issue.
Thank you. I recorded this one without rehearsal, so was genuinely surprised when this issue came up
Another way to start the container once before all test cases is to let testcontainers control the lifecycle by using the Container annotation, but define the container in a companion object. It’s unlikely to Chang a much for you though.
Example:
```
@Testcontainers(disabledWithoutDocker = true)
class EventStoreDbExamples : EventStoreContract(EventStoreDbEventStore(eventStoreDb.connectionString)) {
companion object {
@Container
private val eventStoreDb: EventStoreDbContainer = EventStoreDbContainer()
}
}
```
Thank you. I realise that I haven’t really looked at the container lifecycle properly - watch this space next week
You don't really need to initialize the container yourself... the tc driver will do it for you, in the docs it shows what connection string you can use that postgres will be started for you. The only thing is that there are less configuration options in that case.
Ah interesting - do you have a link please?