"Does It Have Green Unicode Ticks?" is my first go/no go heuristic when evaluating a test runner. Amazing how many fail! Glad to see there's an option in Go.
Seriously, no sarcasm here. I have a green tick addiction and need my fix.
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)
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/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.")
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 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.
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!
I am fairly impressed with this actually. Live code refresh and showing results in the browser is very cool. Definitely this project can be extended to have OS-level notifications with the help of browsers (e.g. Chrome).
Also this approach can be adopted in many languages which doesn't have a rich IDE (e.g. Visual Studio or XCode). Are there any similar tools you know of in other languages?
A friend and I were trying to achieve that this summer via some various hacks, for a Java stack.
My friend ended up running the test script in a `while; sleep` loop, and made the script generate an ugly HTML page of the test result. He'd then setup Chrome to refresh every x secs.
What we were really wishing for is something like GoConvey - even thought about doing it ourselves when I explored the `fsnotify` package.
All that to say; this is really neat and I can't wait to integrate it in my workflow.
I applaud your efforts. Java could really benefit from browser-based test output, I think.
Until recently, GoConvey was using fsnotify to respond to file changes in the watched directories. We started seeing a lot of "Too many open files" errors, for one reason or another. While fsnotify is a good package, it did more than was needed. All we needed to know is if something changed.
We were able to drop that dependency by simply walking the watched directories and checksumming them as we go by adding up file names and their modification dates. If the checksum is different, GoConvey re-runs tests.
So my understanding is that you should be able to watch 10240 many individual directories. I believe that should be enough to cover any Go project, wouldn't it? What lead to that message?
EDIT 2 : So I see you walk the directories every 250ms per default.
I'll have to double-check with mdwhatcott about the exact details of the open files problem, but I believe it had to do with "ulimit".
Yes, directories are walked continuously, with 250ms between each scan. So far this has worked pretty well (maybe on slower systems it should be slowed down). Over time I hope we'll get performance tweaked to an optimum.
There are several automatic test runners in Go which work from the terminal. Here's one for example: https://github.com/levicook/glitch. Not as pretty, but perhaps more useful if you want to avoid the browser.
You're right; and that's cool, I haven't seen that one before. These auto-testers kind of helped inspire the idea (we just wanted more useful output without going to the terminal).
Keep in mind, too, that GoConvey can automatically without the browser by using an idle.py script that's bundled in. If that's all you need, though, then something more lightweight like glitch looks good.
Seriously, no sarcasm here. I have a green tick addiction and need my fix.