[marginalia_nu]

Testcontainers are for testing individual components, apart from the application.

I built a new service registry recently, its unit tests spins up a zookeeper instance for the duration of the test, and then kills it.

Also very nice with databases. Spin up a clean db, run migrations, then test db code with zero worries about accidentally leaving stuff in a table that poisons other tests.

I guess the killer feature is how well it works.

[dns_snek]

> Also very nice with databases. Spin up a clean db, run migrations, then test db code with zero worries about accidentally leaving stuff in a table that poisons other tests.

Are you spinning up a new instance between every test case? Because that sounds painfully slow.

I would just define a function which DELETEs all the data and call it between every test.

[NomDePlum]

It supports both patterns (and variations in between). So you get to pick between isolation at a test level or if you want less overhead, rolling back the commit or other ways to cleanup.

Can only speak for the Golang version of the lib, but spinning up new instances was surprisingly quick.

[marginalia_nu]

I usually do one per suite with a reset method run before each test.

It's a decent compromise between performance and isolation, since weird interactions can only originate from the same suite, rather than anywhere in any test. Also permits parallel execution of db test suites.