[hadiz]

At a recent job, people were advocating for ginkgo, a non-standard "reinvents the wheel" type of testing framework in golang. If you don't know golang, it has near perfect tooling out of the box, including a standard test framework.

I joined on the brink of this decision i.e. moving to ginkgo. I was the first and only person to ask what does ginkgo do that "go test" does not for us? Nobody could really answer that.

Turns out, much like myself, and most engineers who weren't Googlers at the time, didn't really know golang and its environment. They all kinda assumed that like any other popular language, esp. for system programming (like C++) golang in its infancy requires a test framework supplement.

Well, no it doesn't. "go test" is standard which if we're lucky, means we never have to re-write tests 10-20 years down the line because it's the standard.

[meddlepal]

I had to go look up Ginkgo... and I'm not sure it's an Apples to Apples comparison. The built-in Go framework for unit testing is great but I don't think I would want to try to write clean BDD tests with it.

Part of the value-prop for Ginkgo is that it gives you a standard BDD DSL which if you're doing BDD is half the battle... describing and testing the behavior with a human-friendly programmatic interface.

On the other hand if none of the team could articulate why they needed Ginkgo that probably means they don't actually know what BDD and your point still stands.

[dillonmckay]

Which, IMHO, would behoove the team to learn BDD conceptually, in order to assess its appropriateness as a tool in any situation.

[quickthrower2]

I’m yet to see BDD used even though I’ve seen BDD frameworks used a lot. BDD frameworks happen to be excellent for unit testing too! They force you to write the testing code to be better because you need to describe each action. I find in normal unit tests developers use shenanigans to shortcut testing something.

[hadiz]

oh yeah absolutely, ginkgo has its use. It was not suited to what we were after, though.

[jimsmart]

> Nobody could really answer that.

Sounds like it was dismissed without evaluation, your comments seem to support this, you seem to think it offers little or nothing over Go’s standard bare-bones testing.

Ginkgo doesn’t re-invent the wheel regarding Go’s out-of-the-box testing, it builds upon it. Ginkgo tests run just fine with ‘go test’, except the output is a little less detailed/pretty. And you can still use standard Go tests alongside Ginkgo, they play just fine together.

Go’s OOTB test story is pretty good. But one cannot easily have hierarchically structured tests, the output doesn’t clearly describe what a failed test was testing, one cannot easily enable/disable whole sections of tests (while getting reminders that tests are ‘pending’ so one doesn’t forget about them later), randomised test ordering, clean/easy before(after test methods. And those are just the features I use, from the top of my head — it does much more.

And Ginkgo is usually paired/installed with Gomega. Assertions written with Gomega are very easy/nice to read, no matter what kinds of values one is checking, and Gomega also includes all manner of helpers for assertions and matchers.

Go’s OOTB testing is pretty good. But eventually one will realise that one is re-inventing wheels when writing yet another bunch of testing helper funcs — then the path either leads to building one’s own library of helpers, or realising that someone has already done a good job of this already.

I’ve been programming Go for a few years now. For some smaller projects, I just use the standard testing stuff, but for others I can write more readable tests, test more thoroughly, and write such tests in much less time when I use Ginkgo and Gomega.

[hinkley]

God. I had to take over R&D of a service at work and despite the rest of our division already using 2 unit testing libraries and 3 testing idioms, they picked a fourth and a totally different reporting tool.

To be fair, one of those I introduced, because the oldest one we were using was demonstrably broken and prone to human error. I followed it up by shopping it around and getting others on board. One guy I deputized got a promotion in part from finishing what I started. The old one is just barely hanging around due to inertia and fear of breaking changes, but the coverage (% of overall, and I'm pretty sure LoC as well) continues to dwindle.

These guys picked a new one and then did nothing. Never talked about it, never pitched it to anybody, just forked our testing process. If that was the biggest problem with this code I'd just roll up my sleeves and fix it, but they broke so many other rules too - ours and ecosystem rules - that this is the least of the problems with the code. I might get around to looking at it in six months. I've been working on it for three months already.

[domlebo70]

> If you don't know golang, it has near perfect tooling out of the box, including a standard test framework.

Does it really?

[jopsen]

I would agree, "near perfect" seems a bit extreme.

But golang tooling is often simple and "good enough", which IMO is sometimes the best option available :)

Never underestimate "good enough" - it's good enough :D (But don't try to explain that to someone you're dating, LOL)

[legulere]

Integrated stuff can sometimes also be borderline unusable. For the .NET project we’re currently working on we decided to log using system.diagnostics.tracesource and co. It happens rather regularly that we wonder why something doesn’t get logged and we wonder where something gets logged to.