A small appreciation for testing in Go

<p>I really like that tests are typically in the same folder as the production code they test. It&#39;s a small thing, but a recent venture back into Ruby made me appreciate it.</p> <hr/>**评论：**<br/><br/>etherealflaim: <pre><p>I&#39;m a big fan of the whole of Go testing. The simple minimalistic testing library, table driven tests, subtests, and the speed at which they run.</p></pre>pigassmotherfucker: <pre><blockquote> <p>the speed at which they run</p> </blockquote> <p>That’s another thing I really like about testing Go. I don’t even filter the tests I run anymore because I can run all the tests in the project in less time than it takes to think about what tests I should run. </p></pre>adambkaplan: <pre><p>FWIW your tests don&#39;t have to be in the same package as your code. However, you can only test against exported (public) methods if you go this route.</p> <p>I&#39;m on a large go project where we have the whole gamut - unit tests for the deep business logic, integration tests against exported APIs, and end-to-end tests which drive our CLI against running servers.</p></pre>moomaka: <pre><p>As counter point from someone that also works in Go and Ruby, this kinda annoys me. I prefer the test suite being in a separate directory and don&#39;t find them next to each other to be particularly useful as with a standard naming conventions many editors can get you to the test file easily as is. e.g. cmd-shift-t opens the test file for your current file in rubymine.</p></pre>BaconGobblerT_T: <pre><p>I agree, but not for the same reasons you pointed out here.</p> <p>I&#39;ve found that the current system is great. Having tests in the same package as your source code allows you to test private functions defined within the package. However, I&#39;ve also found that if users consume your package, it&#39;s a great practice to write tests in a separate test package. That way, you can test a package as if you were an end user, thus making you think about how you structure your package for external use. It also serves as documentation for developers to figure out how they can handle certain use cases as well as write better unit tests when fixing bugs.</p></pre>curiousGambler: <pre><p>A note for those unaware: you can have tests external to the package in the same directory by naming the test package itself with the ‘_test’ suffix (in addition to the file as usual). For packages I’ll often have both internal and external tests within the same directory as the package code itself. </p></pre>moomaka: <pre><blockquote> <p>Having tests in the same package as your source code allows you to test private functions defined within the package.</p> </blockquote> <p>If you have to organize code in a particular way in order to make it testable I consider that a bug against the programming language.</p></pre>SaltTM: <pre><p>Have to agree and typically you don&#39;t want to deploy test code to the live server. There&#39;s no reason to.</p></pre>moomaka: <pre><p>I don&#39;t find that to be a good reason for the separation. What I find problematic is the separation of test support code. There isn&#39;t a great and logically separated place to put setup and support code when your tests live in the same directory as your production source files.</p> <p>i.e. putting your test code in the same directory as the source files is fine if all you do is unit test, but I find unit tests to be the least useful type of test. Testing composite layers requires setup and support and doesn&#39;t have a clear answer for organization in the Go model.</p></pre>