breadsmasher@lemmy.world
on 09 Aug 2024 13:17
nextcollapse
What is the specific use case of these, relating to unit testing?
Why not just have the container execute unit tests, once that process ends and the container closes itself? This wouldn’t need anything additional.
akash_rawal@lemmy.world
on 09 Aug 2024 13:30
collapse
I don’t get it, how would a database container run your unit tests? And unless you know some secret option to stop the database after, say, it is idle for a few seconds, it will continue running.
The purpose is to test database dependent code by spinning up a real database and run your code against that.
breadsmasher@lemmy.world
on 09 Aug 2024 13:38
nextcollapse
Ah! That’s what I didn’t understand. So its not a container for executing unit tests. Its a container for dependencies to support unit tests. That is not clear from the readme unless I missed something
edit - the title could be “Self terminating containers for real world dependencies to support your unit tests”
akash_rawal@lemmy.world
on 09 Aug 2024 14:30
nextcollapse
Thanks man, my brain was short-circuited on Testcontainers so I couldn’t write better. Also I am stealing the title.
MagicShel@programming.dev
on 09 Aug 2024 14:38
collapse
This feels more like an integration test than a unit test to me. Maybe that’s not an important distinction to make, but it feels like it would also help communicate intent.
adam@doomscroll.n8e.dev
on 09 Aug 2024 15:23
collapse
I’m reading this scratching my head going “If your unit tests need a database they ain’t a unit test”.
threaded - newest
What is the specific use case of these, relating to unit testing?
Why not just have the container execute unit tests, once that process ends and the container closes itself? This wouldn’t need anything additional.
I don’t get it, how would a database container run your unit tests? And unless you know some secret option to stop the database after, say, it is idle for a few seconds, it will continue running.
The purpose is to test database dependent code by spinning up a real database and run your code against that.
Ah! That’s what I didn’t understand. So its not a container for executing unit tests. Its a container for dependencies to support unit tests. That is not clear from the readme unless I missed something
edit - the title could be “Self terminating containers for real world dependencies to support your unit tests”
Thanks man, my brain was short-circuited on Testcontainers so I couldn’t write better. Also I am stealing the title.
This feels more like an integration test than a unit test to me. Maybe that’s not an important distinction to make, but it feels like it would also help communicate intent.
I’m reading this scratching my head going “If your unit tests need a database they ain’t a unit test”.
So it’s not for unit tests, that’s where the confusion stems
cool, we need more tooling around rootless docker / podman