I don’t like the “solves the problem of your test running fine in isolation but fails when run in concert with other tests”.
If you have that problem you have poorly written tests. > On Jul 29, 2021, at 2:05 PM, Andrew Werner <awerne...@gmail.com> wrote: > > > Another choice to throw into the mix is > https://github.com/cockroachdb/copyist. It comes with different trade offs > but if you buy into its framework, it should be much faster than running the > database. > >> On Thu, Jul 29, 2021 at 3:13 AM Brian Candler <b.cand...@pobox.com> wrote: >> 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. > > -- > 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/CA%2BvRuzPvz%2Bu2NCubgnWEiu-D29HVj13tGxUHmEVpaTTdcqyO0Q%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/D3303112-FD44-4548-9A54-844A4D3C5211%40ix.netcom.com.
