Go Unit Testing General Library

<p>I Have found that when writing unit tests, I often have a slice of an implicitly defined struct called <code>cases</code> where I have an input and an output, and later I have a for loop that iterates over said cases slice. I often have to type very simlilar code over many unit tests, which is bad practice from my understanding. Is there a library that generalises this function of having a slice of cases then iterating over it for unit tests?</p> <hr/>**评论：**<br/><br/>pdffs: <pre><p>Your test cases are almost always of a specific type that relates to the code that you&#39;re testing though, so there&#39;s not really any way to abstract it sensibly.</p> <p>There&#39;s also the adage: <em>A little copying is better than a little dependency.</em></p></pre>rwaweber: <pre><p>It&#39;s very possible that I&#39;m misreading your question, but what it sounds like you&#39;re describing is kind of in the realm of the concept of <a href="https://github.com/golang/go/wiki/TableDrivenTests" rel="nofollow">table testing</a>.</p> <p>That way you can illustrate test cases as data. I&#39;ve found that it helps to iron out more edge cases as I write them, looking at them all grouped together.</p> <p>A good, albeit a little complicated example I&#39;ve been studying lately <a href="https://github.com/Shopify/sarama/blob/master/client_tls_test.go" rel="nofollow">here</a>.</p></pre>creikey: <pre><p>Yes, that&#39;s exactly what I&#39;m describing! Thank you! I think I could easily turn this into a small library to make error messages more uniform. Thanks</p></pre>dlsniper: <pre><p>No, you can&#39;t, because you don&#39;t have generics in Go and because that library would have to accept an input and an output set of values, and all it would do would be to use a for loop and run the tests against the input value. Don&#39;t try to abstract the wheel when there&#39;s nothing to abstract.</p></pre>drvd: <pre><blockquote> <p>which is bad practice</p> </blockquote> <p>Why should this be bad practice? I think uniformity of code is a good thing. Call this a &#34;pattern&#34; and have a good day. Nothing to worry here.</p></pre>creikey: <pre><p>If I want to change something small with the t.Errorf función, I have a lot of refactoring to do</p></pre>shovelpost: <pre><p>You can always use <code>got</code> and <code>want</code> or <code>have</code> and <code>want</code> as your variables. That way you don&#39;t have to change that much on refactoring.</p></pre>drvd: <pre><p>Now I&#39;m confused. I have no idea how your original question is related to this reply. Probably you should show code.</p></pre>kostix: <pre><p>You might want to use <a href="https://github.com/stretchr/testify/" rel="nofollow"><code>github.com/stretchr/testify</code></a> then—basically it allows you to spill <code>assert.Whatever</code> instead of hand-crafted calls to <code>t.Errorf</code> as it has sensible idea about how to write what happened.</p></pre>