ginkgo VS Gauge

Debug both standard applications and Ginkgo tests (this is what I'm using at the moment 🤷)

Let's explore a simple test, as it looks now in the code base (the code uses Ginkgo and Gomega, a somewhat overlooked combination IMHO)

Take a look at the Ginkgo testing framework to see the horrors of shoe horning FP into Go

https://onsi.github.io/ginkgo/#writing-specs

It's the same with the Ginkgo testing library: "After the package books_test declaration we import the ginkgo and gomega packages into the test's top-level namespace by performing a . dot-import. Since Ginkgo and Gomega are DSLs this makes the tests more natural to read."

https://onsi.github.io/ginkgo/

The ginkgo testing framework helps us in building the test suite. It's entirely written in Go. Furthermore, it provides a CLI utility to set up and run the tests. Since we will use it later, let's download it from here. You can download it in two ways:

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.

Selenium is cool but https://gauge.org/ really cuts down on the boilerplate and is a lot more lightweight, may want to give it a look too

This actually reminds me a lot of Gauge from Thoughtworks: https://github.com/getgauge/gauge

It's typically paired with Taiko for test automation, but generally speaking it's a markdown to logical instruction engine.

I dig it, but also worth taking a look at what the Thoughtworks team has done especially around the VS Code tooling and language server work that they did to bring intellisense into their Markdown templates.

Since the project also uses Postgres, Redis, and AMQP, we also write integration tests. A docker compose file is there to stack up the test suite, and before each test, the tables, the keys, and the queues are reset. We don't try to aim to test for all the cases but usually all the controllers are covered. I personally would prefer to write more test cases between multiple micro services (e2e?) using something like Gauge but these integration tests are kind of enough.

Gauge looks interesting, but reminds me heavily of BDD frameworks - it looks like it's an abstraction layer where instead of writing Gherkin/GWT, the tests are in their specific DSL that's Markdown based?

Gauge is a Behavior Driven Java testing framework launched by ThoughtWorks.Inc. This is also one of the best Java Testing Frameworks, which allows software engineers to develop automated frameworks and speed up the software development procedure.