gomega

We make use of https://github.com/onsi/ginkgo and Gomega https://github.com/onsi/gomega for BDD testing with more expressive matchers. You might be familiar with some of these concepts from Cucumber/Jasmine/Mocha. They get significant use in Cloud Foundry and in the Kubernetes e2e tests. I appreciate a lot of people like the simplicity of the standard test library and if you're starting with Go development, it's not a bad idea to get used to that before exploring external dependencies. Caveat: While not necessarily a "maintainer", I have been doing a bunch of maintenance on these projects the past few weeks. Edit: Also we use counterfeiter https://github.com/maxbrunsfeld/counterfeiter for fakes.

Hi Everyone, I am looking for remote opportunities as consultant and contractor. I have more 12+ years software engineering experience working for companies like Telerik and Pivotal. At Telerik, I was a senior engineer building their UI components for Desktop and IOS Devices as well as their cloud IDE (git integration). At Pivotal, I was engineering lead working on Cloudfoundry PaaS, where I was building Garden Linux Containers (an open source containerization technology tailored for CF). After that, I was leading PCF RabbitMQ team where we were building and operating RabbitMQ for Cloudfoundry. Languages: Golang, Ruby, C#, Objective-C, TypeScript, FlowType Web: React, Redux, Redux-saga, Redux-Logic, BlueprintJS Other Technologies: Ansible, BOSH, Concourse CI Methodologies: Scrum, XP, Pair programming and TDD Github: github.com/svett Linke

I've seen things like: go-supertest - https://github.com/franela/go-supertest and gomega - https://github.com/onsi/gomega And while appealing in some ways, I always end up at the same place: In many instances these tools seem to go against the principles of idiomatic go. I realize I could be totally wrong, and I also see how being diligent about state is theoretically useful for efficiently identifying/exposing points of failure. but many of the go unit-tests I end up writing take a fair amount of effort for setting up the proper state. And then everything else is pretty much a 1-3 liner to check for failures. If you look at http://onsi.github.io/ginkgo/, I think you'll see what I mean. It's shoe-horned in there. SO, what do you all do that you think is amazingly awesome or at least best-practices beyond golang.org recommendations to co

(context: i've been working mainly with python, and have almost no experience with go) My initial reaction to the example was that it looked like something that could be easily unit-tested, without the added layer of BDD over the top. But that's probably just a symptom of the example appearing as something that would be simple to build and test. E.g. in python i'd translate `Expect(scoreKeeper.Stats["Manning"]["Touchdowns"]).To(Equal(1))` to `assert scoreKeeper.Stats["Manning"]["Touchdowns"] == 1` which is essentially the same, but only uses one bit of machinery (assert) rather than three. That said, the more ways to test things the merrier. I think if you are interested in testing larger chunks of functionality / user-facing bits of behaviour rather than invariants of the building blocks of your program, then perhaps BDD starts to look m