embedded-postgres VS ginkgo

So what can you do insted? For testing databases, setup a docker instance for tests (e.g. like in https://github.com/ardanlabs/service), or start an embedded-postgres daemon (see https://github.com/fergusstrange/embedded-postgres). For communication with external APIs, just pass the http.Client (either in context.Context or as a field on the struct). Then in tests, you can override the http.Client.Transport func.

There's also this interesting project, which embeds postgres into your binary: https://github.com/fergusstrange/embedded-postgres

This is down to nuance, but all databases are "file based" as they all write to files. But most of them require a separate process with lock coordination to get away from writer lock delays and ensure ACID, which includes Postgresql. Calling any version of pgl "embedded" is confusing because I see that being used to describe pgl databases which are run in a localhost mode with a single reader/writer client. Regardless, those still require a postgres process and access it over IP. For simplicity, if one uses a database by touching its files directly from the process accessing the database, then it's "embedded"; but then again I guess that semantic ship has sailed: https://github.com/fergusstrange/embedded-postgres so the point may be moot.

depending on the language you have chosen for your side project you might also be able to run postgresql in embedded mode here is the one for golang https://github.com/fergusstrange/embedded-postgres . There is similar solution for java as well.

If you are using Ginkgo for your e2e, this library might of help.

https://onsi.github.io/ginkgo/ offers a simple way to create tables with different scenarios useful to generate different test cases based on a file like a yml without to need to develop useless code. Maybe at start seems to be a little verbose but depends how you design the test case.

If you like BDD and more expressive tests, go get ginkgo. It is a pain in the back get the hang of its R-spec like syntax, but if you're good at it and you like it, it is very expressive and readable. It has its own matcher (assertions library), gomega, but if you don't like it, you can still use testify instead.

What are people’s thoughts on testing frameworks? I’ve heard that most devs only use the testing package in the standard library and the testify package for assertions— I assume this is because Go is meant to be lightweight and scalable, and adding external dependencies basically goes against that. But I’ve also seen devs use packages like ginkgo to make tests more structured and readable. What do you guys think?

Ginkgo Behavioural test framework

If you write your tests with Ginkgo [0] its CLI can do this for you. It also has nice facilities to quickly disable a test or portion of a test by pretending an X to the test function name, or to focus a test (only run that test) by prepending an F. It’s pretty nice.

[0]: https://onsi.github.io/ginkgo/

The BDD testing framework Ginko [1] has some "weird" / unidiomatic patterns, yet it is very popular

https://github.com/onsi/ginkgo

To settle an argument amongst my coworkers, I started a Twitter poll on using Gingko for golang unit testing. Some like the framework because it makes tests clean. Others hate it with a firey passion.

As a big fan of automated testing, it’s comforting to learn that we can easily write tests for our controllers using envtest (which runs a local k8s control plane so we can run our tests against it), the Gingko testing framework and the Gomega matching/assertion library: