SHshoo·Oct 10, 2013
(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
Read the rest
ore 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