BDD testing for golang: Ginkgo and Gomega
pivotallabs.com
BDD testing for golang: Ginkgo and Gomega
1–10 of 29 posts
Re: BDD testing for golang: Ginkgo and Gomega
#2First of all, good job.
Are you planning to add selenium support?
Re: BDD testing for golang: Ginkgo and Gomega
#3Looks great. I'm a huge fan of RSpec and really miss it in other languages. It didn't occur to me before reading this post, but the ability to implement a testing framework like RSpec is a great way to gauge the expressiveness of the language.
Re: BDD testing for golang: Ginkgo and Gomega
#4I 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.
Re: BDD testing for golang: Ginkgo and Gomega
#5I 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.
Re: BDD testing for golang: Ginkgo and Gomega
#6I 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.
(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 the same thing as this, that have pre and post conditions and assertions and explanations in comments. The whole point of static type systems, surely, is that you represent things (constraints, state, possible values, etc) in code rather than comments and rely on the language to enforce them rather than the next developer to read your comments, so the explosions happen at compile time rather than production. So, by that token, this kind of DSL seems like a step in the direction of static typing, rather than the other way round.
I've not looked at the source, but the line `Expect(scoreKeeper.Stats["Manning"]["Touchdowns"]).To(Equal(1))` might use all kinds of clever closure stuff but ultimately wouldn't compile if the right interfaces weren't satisfied. Unless there are `interface{}`s all over the place, which would be regrettable.
On the surface, this seems like a step toward Ruby with its endless DSLs which feels like the antithesis of static typing. That naturally feels a bit weird and a bit of a culture lurch. But perhaps the DSLs are closer to those of Scala than Ruby.
Both feelings I get are fuzzy and not particularly arguable, but I think peoples' relationships with languages are very personal and that's such a fundamental quality of the PL landscape that it's worth not discounting.
Re: BDD testing for golang: Ginkgo and Gomega
#7Earlier 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…
DSLs are not the antithesis of static typing. Beware of using the word strong when discussing type classification. That word is highly muddled and doesn't mean the same thing to everyone.
Haskell, for instance, is statically typed and does DSLs very very well. In fact, you use the type system as an augmentor of the DSL: it sets up the rules for how to embed the DSL in the code base itself. And it disallows a class of programs which would not work at all.
The right way to view types is that they allow a far richer description of what your code is doing because you can discriminate values on their types.
And before you lynch me: my professional work job is in Erlang which is a dynamically typed language.
Re: BDD testing for golang: Ginkgo and Gomega
#8Interesting choice of the Omega symbol for the actual symbol. Not sure if I like that or not. Vim users can use CTRL-K W * in insert mode to get a nice block character (at least on my build of vim) on their screen.
I prefer to use Gherkin syntax for by bdd testing, but the matchers are nice. The bootstrapper and helpers seem to fail hopelessly on windows, and the console writer outputs a lot of control characters which do not work in windows command prompt.
Re: BDD testing for golang: Ginkgo and Gomega
#9This is totally awesome.
Re: BDD testing for golang: Ginkgo and Gomega
#10Earlier 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…
DSLs are not the antithesis of static typing. Beware of using the word strong when discussing type classification. That word is highly muddled and doesn't mean the same thing to everyone. Haskell, for instance, is statically typed and does DSLs very very well. In fact, you use the type system as an augmentor of the DSL: it sets up the rules for how to embed the DSL in the code base itself. And it disallows a class of…
You're right. Strong and static occur so often together (Go is both strong and static (mostly), for example) that I fell into the trap of glomming them both together. I've edited my post.
EDIT: And when I said 'the antithesis of static typing' I meant purely in the Ruby context, which is famous for its DSLs.