<p>I recently read that the testing library Ginkgo (<a href="https://onsi.github.io/ginkgo/">https://onsi.github.io/ginkgo/</a>) is one of the most popular go libraries (<a href="https://medium.com/@_orcaman/most-imported-golang-packages-some-insights-fb12915a07">https://medium.com/@_orcaman/most-imported-golang-packages-some-insights-fb12915a07</a>)</p>
<p>I promptly tried it out, loved the BeforeEach functionality, and then got a race condition via closure. While it makes the tests look a little more pretty (if you like grouping), you can't really run the tests in parallel and you can't get access to testing.T.</p>
<p>So what's the appeal? Is it just that it looks like rspec? Seems like extra overhead for slower (non-parallel) tests.</p>
<hr/>**评论：**<br/><br/>wastedzombie219: <pre><p>Before subtests were added go test made it hard to run suites. I can't imagine anyone post go 1.7 starting a new codebase with ginkgo or or one of the junit style runners. </p></pre>thockin: <pre><p>We use it a lot in Kubernetes, and I wish would would kill it with fire.</p></pre>fasaxc: <pre><p>I think a lot of coders come to Go, don't buy the "you shouldn't use a test framework" argument and go looking for one. At this point, Ginkgo is popular, and it looks a bit like what they're used to so they go for it. It also has features like </p>
<ul>
<li>focusing tests</li>
<li>running each test spec in a clean copy of the state to avoid leakage between tests (this isn't a bug; each It is supposed to run separately)</li>
</ul>
<p>I've fallen out of love with Ginkgo at this point; it's got a heavy functional programming learning curve with all the closures and deferred evaluation that it does.</p>
<p>I <em>still</em> don't get the vague "assertions are bad" argument in the Go docs. There's enormous value to me in an assertion library like Gomega (which is the library used to do assertions in Ginkgo). It takes care of 99% of my pretty-printing needs after a failure; I don't want to have to write this 10,000 times:</p>
<pre><code>if a != b {
// fail the test, remembering to log out a and b
// return
}
</code></pre>
<p>and I do't want to wrap it up in a utility function; I want a library that has it already!</p></pre>SeerUD: <pre><p>100% agree. Assertion libraries are well worth it. I'd just commented elsewhere about this. My experience has been they make tests easier to both read and write.</p></pre>tmuxxxer: <pre><p>Assertion libraries help convert intent. I prefer <a href="https://github.com/apoydence/onpar/tree/master/matchers" rel="nofollow">https://github.com/apoydence/onpar/tree/master/matchers</a> over Gomega. It's more lightweight.</p></pre>dvirsky: <pre><p>I usually use testify/assert (<a href="https://godoc.org/github.com/stretchr/testify/assert">https://godoc.org/github.com/stretchr/testify/assert</a>) and it's simple and gets out of your way. It just saves me time/lines in writing tests.</p></pre>natefinch: <pre><p>So, an important note... that list is of "most imported"... it's counting the number of packages that import a specific library. The problem is that the methodology is flawed (or at least, rewards a specific type of library).</p>
<p>Note that in the top 10 there are 4 testing packages and two logging packages. Why is that? Because when a project decides to use a third party test framework or logging library, they usually use it for every single package in the project. That alone makes one project with, say, 20 packages, import that library 20 times. </p>
<p>Note that the juju/errors library is listed there. If you look on godoc at who imports it... it's not actually used very much outside juju... it's just that juju is a huge project with a ton of packages that all import it <em>and</em> every dev's fork of juju also imports it, which godoc (and likely this tool) count as a separate projects. So now you have juju's 500 packages importing it times 30 devs, makes it look like 15000 imports... when really it's just a single logical project. </p>
<p>So, I'd take this with a huge grain of salt.</p></pre>jrwren: <pre><p>THIS! <sup>^</sup></p>
<p>The bigtable query linked from the OP shows how "most imported" is measured, and it isn't even per package, it is per file.</p>
<p>I could create a package with 3,000,000 files in it, each of which declares a variable of some type, and imports any package I want that includes that type.</p>
<p>SELECT line, count(*) as n
FROM (
SELECT SPLIT(content, ‘\n’) as line
FROM go_files.contents
HAVING LEFT(line, 7) = ‘import ‘
)
GROUP BY line
ORDER BY n DESC
LIMIT 10</p>
<p>This is not useful data.</p></pre>wubrgess: <pre><p>What I really hate about it is that it doesn't really support multiple verification well because inside of the It function any failing verification kicks out to the caller. The other option is to run multiple Its but then it actually runs the test again (before each) instead of just using the existing results!</p></pre>recurrency: <pre><p>I still can't understand why tests can't be kept simple, sugarfree and especially: free of any frameworks.</p></pre>eikenberry: <pre><p>I'm sure you meant this as a rhetorical question.... but you of course know they can be. This project just chose to use a framework, others do not.</p></pre>SeerUD: <pre><p>I like subtests, I don't think that something like Ginko is necessary at all. But I would argue that assertion libraries make testing much simpler (i.e. easier to both read and write). Sure, you have to take the minute to learn the methods you have available, but with something like Testify the method names are so easy to understand and even guess when you're first starting out. </p>
<p>I found that introducing an assertion library, even a super simple one with just 6 helper functions made a big difference to how easy it was to write tests, and then read them again later. This is subjective though, I understand that people don't like to pull in libraries for everything, but in my opinion, the time and mental energy saved has made using at least an assertion library well worthwhile.</p>
<p>I've also found they can help make the output of the tests much clearer when something fails. It helps take away the tedious "expected bla to equal bla but got bla" message typing too.</p></pre>recurrency: <pre><p>I don't oppose assertion helpers — they can indeed be handy to reduce some boilerplate. </p>
<p>However, what I have found myself doing a lot is to write table-driven tests. Then the time spent on writing the cases will dominate the "test fail"-logic by an order of magnitude.</p></pre>redditbanditking: <pre><p>I think a lot of these come to people's personality. I prefer my tests to be simple assertions too. Some others prefer a stylized BDD like this with verbose documentation.</p>
<p>And check out <a href="http://onsi.github.io/gomega/" rel="nofollow">Gomega</a>, Ginkgo's matcher library. What da fuk is this: <code>Ω(ACTUAL).Should(Equal(EXPECTED))</code>. An actual omega symbol as a function name? Nein danke.</p></pre>skidooer: <pre><p>I have become convinced that this is the natural lifecycle of a programming language. It starts simple and sugarfree and then people start working on layers of abstraction. Eventually those abstractions become so layered that nobody understands it anymore. Then, everyone moves to a new language that has a simple and sugarfree environment that they can understand again. The cycle continues.</p></pre>santriseus: <pre><p>Sometimes when users come to golang from other languages, they try to find the tool/approach they are familiar and comfortable with in their language.
I like to write the BDD-like tests using the combination of mocha + chai in javascript, so I would like to find something similar in golang, despite the fact it is not the "ideomatic" way. Ginko+Gomega looks the closiest tools to Mocha+chai for me.</p></pre>SeerUD: <pre><p>I get the appeal here. I came from Scala and used Scalatest in a similar way to Mocha + Chai, and it is very nice. Nice reporting on the end, etc. Maybe people would like a more idiomatic implementation of a testing framework like Ginko? Something that lets you run tests in parallel still?</p></pre>ragefacesmirk: <pre><p>Have you checked out <a href="https://github.com/apoydence/onpar" rel="nofollow">https://github.com/apoydence/onpar</a></p>
<p>It lets you do BDD style tests, all in parallel.</p></pre>SeerUD: <pre><p>This looks really nice!</p></pre>fthedill: <pre><p>This is neat. Looks similar enough to move Ginkgo projects to this.</p></pre>ragefacesmirk: <pre><p>I hate when you run <code>ginkgo -r</code> it doesn't run each package in parallel like go test ./... does. No ones got time for that!</p></pre>random314: <pre><p>I don't like it at all. There's nothing idiomatic go about this. It's like trying to cram mocha and chai into go's simplicity, it's just not right.</p></pre>xchapter7x: <pre><p>If you prefer the BDD flavor of TDD and are doing go development, that's why it exists. So it's popularity is probably speaking more to the popularity of BDD in the go community than anything else.</p></pre>robvdl: <pre><p>I imagine this is popular with developers having done a lot of JavaScript because it pretty much seems to copy the style of tests from Jasmine. First time I saw it I thought it was inspired by Jasmine.</p></pre>ragefacesmirk: <pre><p>Both Ginkgo and Jasmine were written by a people who work at Pivotal. </p></pre>[deleted]: <pre><p>Go was newish at the time these libs came out, and a lot of people were bringing their heavy expectations for heavy frameworks from other languages, primarily the rspec crowd from ruby/rails (I admittedly was one of them). It's same reason logrus took off. </p></pre>mdwhatcott: <pre><p>We all choose tools that help us achieve results. No two developers or teams or projects are alike. All use cases are different. Any extreme mantra (ie. "Never use a test framework!!!" or "Always use an assertions library!!!") cannot possibly be correct in every situation.</p></pre>gee55: <pre><p>I use it solely to run tests on change (with normal go tests). <code>ginkgo watch -r</code> is the best test runner.</p></pre>alex_sly: <pre><p>Some features that I like:</p>
<ul>
<li>It is easy to run only subset of tests or skip subset of tests</li>
<li>it is easy to run tests in parallel</li>
<li>it is easy to multiple runs to find a flaky test</li>
<li>GinkgoWriter is a nice integrated IOWriter that hides all output for successful test, but shows for failed.</li>
<li>Test suits is a good way to organize tests. For most cases my setup is almost the same - BeforeSuite, BeforeEach, JustBeforeEach are really helpful.</li>
</ul>
<p>I could implement such features in my projects for bare Go tests, but Ginkgo provides unification.</p></pre>shovelpost: <pre><p>Yesterday I downloaded a Go program. It had a makefile which as soon as I did make started listing all the dependencies it was downloading. It was relatively fast till it reached to the cobra dependency which paused the procedure for 5-7 seconds.</p>
<p>Knowing that cobra is a completely unnecessary dependency, that slowdown made me feel sad for the ecosystem.</p></pre>SeerUD: <pre><p>What makes you think that Cobra was a completely unnecessary dependency? Was the program literally only parsing flags, or did it have sub-commands?</p></pre>shovelpost: <pre><p>Compared to the rest of the program, Cobra was a huge dependency and it could easily be avoided. And no it didn't use sub commands.</p></pre>SeerUD: <pre><p>Right, that does make sense then. No sub-commands means you can just use flags for sure. Fair enough.</p></pre>
