1. 12
  1.  

  2. 11

    why to people have the need to use a framework for everything, like the BDD testing frameworks in this article. i really don’t see the value of it. it’s just another dependency to carry around, and i can’t just read and understand what is happening.

    what is gained by writing:

    Expect(resp.StatusCode).To(Equal(http.StatusOK))
    

    instead of

    if resp.StatusCode != http.StatusOK { 
        t.Fail() 
    }
    
    1. 11

      I don’t use that particular testing framework, but the thing I’d expect to gain by using it is better test failure messages. I use testify at work for almost precisely that reason. require.Equal(t, valueA, valueB) provides a lot of value, for example. I tried not to use any additional test helpers in the beginning, probably because we have similar sensibilities. But writing good tests that also have good messages when they fail got pretty old pretty fast.

      1. 3

        ok, i can see that good messages may help, though i’d still rather use t.Fatal/Fatalf/Error/Errorf, maybe paired with a custom type implementing error (admitting that it’s a bit more to type) if a custom DSL is the alternative :)

        testify looks interesting though!

        1. 4

          testify is nice because it isn’t really a framework, unless maybe you start using its “suite” functionality, which is admittedly pretty light weight. But the rest of the library drops right into the normal Go unit testing harness, which I like.

          I did try your methods for a while, but it was just untenable. I eventually just stopped writing good failure messages, which I just regretted later when trying to debug test failures. :-)

          testify is a nice middle ground that doesn’t force you to play by their rules, but adds a lot of nice conveniences.

      2. 6

        The former probably gives a much better failure message (e.g. something like “expected value ‘200’ but got value ‘500’”, rather than “assertion failed”).

        That’s obviously not inherent to the complicated testing DSL, though. In general, I’m a fan of more expressive assert statements that can give better indications of what went wrong; I’m not a big fan of heavyweight testing frameworks or assertion DSLs because, like you, I generally find they badly obfuscate what’s actually going on in the test code.

        1. 4

          yeah, with the caveats listed by others, I sort of thing this is a particularly egregious example of strange library usage/design. in theory, anyone (read: not just engineers) is supposed to be able to write a BDD spec. However, for that to be possible, it should be written in natural language. Behat specs are a good example of this: http://behat.org/en/latest/. But this one is just a DSL, which misses the point I think…

          1. 3

            However, for that to be possible, it should be written in natural language. Behat specs are a good example of this: http://behat.org/en/latest/. But this one is just a DSL, which misses the point I think…

            I’d say that the thing behat does is a real DSL (like, with a parser and stuff). The library from the article just has fancy named functions which are a bit a black box to me.

            Just a thought: One could maybe write a compiler for a behat-like language which generates stdlib Go-tests, using type information found in the tested package, instead of using interface{} and reflect. That’d be a bit of work though ;)

        2. 5

          If you’re curious about writing high security services in Go, I’d suggest taking a look at the code of Boulder, Let’s Encrypt’s certificate authority. Code doesn’t get much more sensitive than that, unless you’re working on a nuclear plant or health devices.