You might also want to look at podman, which runs containers directly as processes under your own userid with no docker daemon - and buildah, the corresponding tool for creating container images. I use them quite a lot for building and running container images before deploying them to kubernetes.
I haven't used the go bindings, but apparently they do exist: https://podman.io/blogs/2020/08/10/podman-go-bindings.html According to that, they are running podman as a service with a REST API, which isn't a million miles from a docker daemon - except that the podman service runs as your own userid, not as root. On Thursday, 29 July 2021 at 06:23:05 UTC+1 amits...@gmail.com wrote: > On Thu, Jul 29, 2021 at 4:39 AM Marcin Romaszewicz <mar...@gmail.com> > wrote: > > > > I have this exact testing issue at my company, we have many Go services > which use Postgres in production, but are unit tested against SQLite. > > > > The latest SQLite covers the vast majority of Postgres queries, so most > tests simply use an SQLite in-memory DB. > > > > For the tests which require Postgres- specific functionality, such as > partitioned tables, for example, we use > https://github.com/testcontainers/testcontainers-go. This is a library > which talks to Docker and can create your test prerequisites as docker > containers and gives you connection information once they're up. This makes > unit tests incredibly slower, but at least functional. > > > > The danger with mocking too much is that your unit tests end up testing > the mocks, and not anything remotely like your runtime environment, so > we've chosen to mock as little as possible. > > Thank you for sharing about testcontainers-go. I have come across > testcontainers, it sounds like a viable solution as well. As with a > lot of things in software, it seems like we just have to see what > works for "us". > > > > > -- Marcin > > > > On Wed, Jul 28, 2021 at 4:09 AM Henry <henry.ad...@gmail.com> wrote: > >> > >> On Wednesday, July 28, 2021 at 3:05:43 PM UTC+7 amits...@gmail.com > wrote: > >>> > >>> That sounds interesting - is the tool generating or is able to > >>> generate SQL for different databases? That must have been a pretty big > >>> effort to create such an abstraction. > >>> > >> > >> It produces different SQL for different databases. It supports a > limited number of databases. Note that quite a number of Go ORM libraries > already support multiple databases. So it is not new. The difference is > that other ORM libraries usually provide a general purpose data access > library, whereas ours generates more specific codes. Other than that, they > serve a similar purpose. > >> > >> -- > >> You received this message because you are subscribed to the Google > Groups "golang-nuts" group. > >> To unsubscribe from this group and stop receiving emails from it, send > an email to golang-nuts...@googlegroups.com. > >> To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/9c81746a-4fb4-4fb5-8e5f-605169a3f2afn%40googlegroups.com > . > > > > -- > > You received this message because you are subscribed to the Google > Groups "golang-nuts" group. > > To unsubscribe from this group and stop receiving emails from it, send > an email to golang-nuts...@googlegroups.com. > > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/CA%2Bv29Lv83-4yDijNmukf0Vx%2BoBVZXJPR11bqA_B5CY1mNhOowA%40mail.gmail.com > . > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/4d6f1b9d-ad44-4fc5-b309-beba2a199382n%40googlegroups.com.
