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.

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.

Ginkgo: a testing framework based on the concept of ‌"Behavior Driven Development" (BDD)

We were also able to leverage Ginkgo's parallel testing runtime to run our integration tests on multiple concurrent processes. This provided multiple benefits: we could run our entire integration test suite in under 10 minutes and also reuse the same suite to load test the operator in a production-like environment. Using these tests, we were able to identify hot spots in the code that needed further optimization and experimented with ways to save API calls to ease the load on our own Kubernetes API server while also staying under various AWS rate limits. It was only after running these tests over and over again that I felt confident enough to deploy the operator to our dev and prod clusters.

A bit off-topic, but i really like the ginkgo BDD framework

You obviously are not familiar with the third circle of golang continuous integration hell that is ginkgo+gomega:

https://onsi.github.io/ginkgo/#adding-specs-to-a-suite

It’s actually worse than that example suggests. Stuff like Expect(“type safety”).ShouldBe(GreaterThan(13)) throws runtime errors.

The semantics of parallel test runs weren’t defined anywhere the last time I checked.

Anyway, you’ll be thinking back fondly to the days of TestShouldReplaceChildrenWhenUpdatingInstance because now you need to write nested function calls like:

Context(“instances”, func …)

Describe(“that are being updated”, …)

Expect(“should replace children”, …)

And to invoke that from the command line, you need to write a regex against whatever undocumented and unprinted string it internally concatenates together to uniquely describe the test.

Also, they dump color codes to stdout without checking that they are writing to a terminal, so there will be line noise all over whatever automated test logs you produce, or if you pipe stdout to a file.

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.

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