Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

BDD testing for golang: Ginkgo and Gomega

pivotallabs.com

Post reply on HN
Print view View original

11–20 of 29 posts

Re: BDD testing for golang: Ginkgo and Gomega

#11

Post by buro9 »

I wouldn't mind a BDD tool written in Go, but not for this purpose.

What I would like is a tool that allowed testers and QA people to define tests using BDD for RESTful APIs.

Something along the lines of this syntax:

    Using https://example.com/myapi
        With access_token [accessToken]
        With content_type application/json
        When I create:
        {
          "somejson": true
          "foo": "bar"
        }
            Expect status 200
            Expect returnData.somejson = true
            Expect returnData.foo = "bar"
            Store returnData.id as myid
    And
    Using https://example.com/myapi/{{myid}}
        When I get
            Expect status 200
            Expect returnData.somejson = true
            Expect returnData.foo = "bar"
    And
        With access_token [accessToken]
        With content_type application/json
        When I update:
        {
          "somejson": true
          "foo": "foo"
        }
            Expect status 200
            Expect returnData.somejson = true
            Expect returnData.foo = "foo"
            Store returnData.id as myid
    And
        With access_token [accessToken]
        When I delete
            Expect status 200
    And
        When I get
            Expect status 404
I've seen a few things like this written in NodeJS, such as apieasy and vows. But nothing with this level of succinctness.

And I'd like it to be in Go as I'd like to just give a single binary to the testers (rather than an "install node, get project, fetch dependencies, resolve any issues, run the project").

When I read the headline, this is roughly what I hoped for. If I can find the time (unlikely), I'd build this. But then... maybe someone reading this knows something very close to this.

Re: BDD testing for golang: Ginkgo and Gomega

#12

Post by shoo »

afandian wrote: post #6
shoo wrote: post #5

Earlier quoted context omitted.

if you are willing to go into more detail, i'd be interested in hearing what these fundamental misunderstandings are.

(Note I am not the GP) This feels weird. I have a gut reaction to this, and it's conflicted. Perhaps the same feeling `redbad` has, perhaps not. On the one hand, I feel like this is a million miles away from the Go I know and love. I've used Ruby, Python, C#, Java, C, Obj-C, JavaScript etc in the past. In terms of mental processes, the way I write go is closest the way I would write C or Java. I write tests that do t…

(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

Re: BDD testing for golang: Ginkgo and Gomega

#13

Post by pjmlp »

buro9 wrote: post #11

I wouldn't mind a BDD tool written in Go, but not for this purpose. What I would like is a tool that allowed testers and QA people to define tests using BDD for RESTful APIs. Something along the lines of this syntax: Using https://example.com/myapi With access_token [accessToken] With content_type application/json When I create: { "somejson": true "foo": "bar" } Expect status 200 Expect returnData.somejson = true Exp…

At the boring enterprise projects we just use SoapUI for this type of testing.

Re: BDD testing for golang: Ginkgo and Gomega

#14

Post by karma_fountain »

shoo wrote: post #12
afandian wrote: post #6

Earlier quoted context omitted.

(Note I am not the GP) This feels weird. I have a gut reaction to this, and it's conflicted. Perhaps the same feeling `redbad` has, perhaps not. On the one hand, I feel like this is a million miles away from the Go I know and love. I've used Ruby, Python, C#, Java, C, Obj-C, JavaScript etc in the past. In terms of mental processes, the way I write go is closest the way I would write C or Java. I write tests that do t…

(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"]["Touch…

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.

Re: BDD testing for golang: Ginkgo and Gomega

#15

Post by afandian »

shoo wrote: post #12
afandian wrote: post #6

Earlier quoted context omitted.

(Note I am not the GP) This feels weird. I have a gut reaction to this, and it's conflicted. Perhaps the same feeling `redbad` has, perhaps not. On the one hand, I feel like this is a million miles away from the Go I know and love. I've used Ruby, Python, C#, Java, C, Obj-C, JavaScript etc in the past. In terms of mental processes, the way I write go is closest the way I would write C or Java. I write tests that do t…

(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"]["Touch…

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.

Re: BDD testing for golang: Ginkgo and Gomega

#16

Post by afandian »

buro9 wrote: post #11

I wouldn't mind a BDD tool written in Go, but not for this purpose. What I would like is a tool that allowed testers and QA people to define tests using BDD for RESTful APIs. Something along the lines of this syntax: Using https://example.com/myapi With access_token [accessToken] With content_type application/json When I create: { "somejson": true "foo": "bar" } Expect status 200 Expect returnData.somejson = true Exp…

I'm writing a project in Go at the moment. I'm actually using Python for exactly this kind of API testing. I see a DSL as obstructive and unnecessary, but that's my point of view.

Re: BDD testing for golang: Ginkgo and Gomega

#19

Post by redbad »

shoo wrote: post #5
redbad wrote: post #4

I can't help but feel like the authors of this tool (and ones like it) are fundamentally misunderstanding either the language, the purposes of testing, or maybe even static type systems in general.

if you are willing to go into more detail, i'd be interested in hearing what these fundamental misunderstandings are.

Like afandian, I'm a little fuzzy on the particulars of my gut reaction. But it's something along the lines of this: that BDD, or TDD, or test-oriented-development-practice-X didn't emerge from the ecosystems of dynamically-typed languages by accident. Those languages lack an entire class of verification that statically typed languages have by default, and which is actually important. So their practitioners abide tools, idioms, and practices to make up for that deficiency.

Those things aren't all bad, and _some_ of their lessons can be successfully "ported" to languages and ecosystems that don't suffer the same fundamental shortcomings as e.g. Ruby or Python. But when I see developers take e.g. the BDD ethos as axiomatic and just run with it, it makes me feel like they don't really understand what BDD is designed to address. Likewise with hyper-expressive testing DSLs, or the concept of "mocking" as it's normally used.

Forgive the loaded language, but bringing BDD et. al. to languages like Go feels, to me, like cargo-cult development.

Post reply on HN