5 ms·

Whilst this looks really neat, given the relative immaturity of testing frameworks in Go, I'd have preferred to have seen something to solve part of these probl

Whilst this looks really neat, given the relative immaturity of testing frameworks in Go, I'd have preferred to have seen something to solve part of these problems individually. Big, complex frameworks such as this are anti-Go. This is bringing notifications, a new DSL, file watching, and whatever else. I haven't reviewed the code, but it seems a shame somehow to lock some useful features up, with some fancy stuff which isn't opt-in-or-opt-outable. Props to the authors, it definitely looks cool, but I can't help but think this, and the "Cucumber for Go" posted a few weeks ago have missed the point. There's decently documented reasons why the Go testing package is the way it is, for a number of reasons (of varying validity). I tend to trust the core team of a language (at least until we've exhausted all the capabilities of the the stdlib and std tools)

arnehormann 13y ago
You should take a look at the code. It uses quite some subpackages, each importable on its own. I didn't look INTO it, but the dependency information from http://godoc.org/github.com/smartystreets/goconvey http://godoc.org/github.com/smartystreets/goconvey and its subpackages paint another picture, it is probably a lot less monolithic than you think... Still, I didn't look at it in depth myself, yet.
- codebeaker 13y ago
  Thanks for taking the time arnehormann, I assumed it would be split into packages at least. But I'd much rather see simple extensions that add setup/teardown, and maybe something that demonstrates how to replace the Test_main function (whatever it's called) for modifying output, probably it's all in here somewhere! Thanks!
mholt 13y ago
Thanks for your feedback. We realize that Go's aim for simplicity is paramount in the design of the language, and wanted to respect that by making the DSL clean as it is. Without worrying what's under the hood, it feels Go-esque, and resolves a few problems. For instance, with native Go tests, your `if` statements have inverted logic: if a != b, then it's an error, instead of, a should equal b. Further, inferring clear intent from just "TestThisOrThat" as documentation is nearly impossible. Fortunately, Go doesn't compile testing packages or files into the final binaries, and the testing framework only has to exist once in your Go workspace, so Go still keeps things pretty tidy. (For the record, I was insistent on using Go's built-in stuff until I realized that the Go engineers were humans too, and the language isn't perfect yet. For example: https://groups.google.com/forum/#!topic/golang-nuts/Kle874lT1Eo/discussion https://groups.google.com/forum/#!topic/golang-nuts/Kle874lT... -- Russ Cox: "The generator we're using only generates 63 bits worth of output. You're right that we probably should have corrected that before the API freeze. Oh well.")

arnehormann 13y ago

You should take a look at the code. It uses quite some subpackages, each importable on its own. I didn't look INTO it, but the dependency information from http://godoc.org/github.com/smartystreets/goconvey http://godoc.org/github.com/smartystreets/goconvey and its subpackages paint another picture, it is probably a lot less monolithic than you think... Still, I didn't look at it in depth myself, yet.

codebeaker 13y ago
Thanks for taking the time arnehormann, I assumed it would be split into packages at least. But I'd much rather see simple extensions that add setup/teardown, and maybe something that demonstrates how to replace the Test_main function (whatever it's called) for modifying output, probably it's all in here somewhere! Thanks!

mholt 13y ago

Thanks for your feedback. We realize that Go's aim for simplicity is paramount in the design of the language, and wanted to respect that by making the DSL clean as it is. Without worrying what's under the hood, it feels Go-esque, and resolves a few problems. For instance, with native Go tests, your `if` statements have inverted logic: if a != b, then it's an error, instead of, a should equal b. Further, inferring clear intent from just "TestThisOrThat" as documentation is nearly impossible. Fortunately, Go doesn't compile testing packages or files into the final binaries, and the testing framework only has to exist once in your Go workspace, so Go still keeps things pretty tidy. (For the record, I was insistent on using Go's built-in stuff until I realized that the Go engineers were humans too, and the language isn't perfect yet. For example: https://groups.google.com/forum/#!topic/golang-nuts/Kle874lT1Eo/discussion https://groups.google.com/forum/#!topic/golang-nuts/Kle874lT... -- Russ Cox: "The generator we're using only generates 63 bits worth of output. You're right that we probably should have corrected that before the API freeze. Oh well.")