[shoo]

(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 more appealing, so the two approaches seems complementary.

Having an expressive static type system is again complementary, as that prevents you from making many trivial errors, and you just have to test for the remaining ones that the type system cannot express. (i miss that in python)

after a little dig through the code, it looks like "EXPECT foo TO EQUAL barr" translates as

https://github.com/onsi/gomega/blob/master/gomega.go#L15 https://github.com/onsi/gomega/blob/master/actual.go#L27 https://github.com/onsi/gomega/blob/master/actual.go#L48 https://github.com/onsi/gomega/blob/master/matchers.go#L7 https://github.com/onsi/gomega/blob/master/matchers/equal_ma...

so there's lots of `interface{}`s and reflection and so on

[karma_fountain]

Unless I'm missing something, assert scoreKeeper.Stats["Manning"]["Touchdowns"] == 1 is not the same unless in python you have some magic reflection. The output you get from that is just pass/fail. The output you get from the matcher method is the expected and actual values in a much nicer error message.

[shoo]

you (& afandian) make a good point, and i believe that's roughly how py.test does it, by rewriting the code of test modules before running tests. which would be fair to call magic.

http://pytest.org/latest/assert.html#advanced-assertion-intr...

[afandian]

Go already has the equivalent of assert, this new library is a reaction to it not being [insert problem here] enough.

The equivalent in Python would actually be building up a whole AST-style object tree full of expressions, and then executing it.