Best practice I should use when it comes to testing using local files?

<p>By using local files, I mean that in order to test functionality, the application needs some local files, as the application reads from these files frequently.</p> <p>I&#39;m not sure if I should write temporary files myself just before running the tests using the ioutil package tempdir and tempfile functions, or create a test folder like so;</p> <pre><code>testing/...test_files_here main.go main_test.go </code></pre> <p>and then read from the contents inside</p> <pre><code>testing/ </code></pre> <p>Thanks</p> <p>Edit: In case anyone comes across this. After further research and confirmation from comments below, I have decided that using a test directory named</p> <pre><code>testdata/ </code></pre> <p>seems to be the best way to go about this. (For me personally anyway, otherwise as <a href="/u/ergotayours">/u/ergotayours</a> mentioned, using an io.reader to fake files could be another option)</p> <p>Some official go packages adhere to this practice also.</p> <hr/>**评论：**<br/><br/>ergotayours: <pre><p>This might be totally irrelevant to your use case, but if the files are very small and just implement some edge case that can easily be implemented in code, you might want to consider passing an <code>io.Reader</code> instead of an <code>os.File</code> to the functions that need to be tested, which will allow you to implement fake &#34;files&#34; and is probably preferable for testing.</p></pre>millerman101: <pre><p>Sounds like an interesting way to mock files, but I am unsure on how I would mock with an io.Reader. </p> <p>Would that involve something like implementing a file struct with the method &#34;read&#34; (satisfying the interface) which would return some mock bytes? </p></pre>hariharan-uno: <pre><p>You could just use <a href="https://golang.org/pkg/strings/#NewReader">https://golang.org/pkg/strings/#NewReader</a> while testing. I would prefer something like this:</p> <pre><code>var x = ` Sample file text ` r := strings.NewReader(x) </code></pre> <p>Now you can pass <code>r</code> wherever io.Reader is the input.</p></pre>millerman101: <pre><p>Ah yes of course! Much simpler</p></pre>ironicAndUnique: <pre><p>I think this is your strongest option. Unless your production code HAS to touch the FS.</p> <p>On a side note, normally you want to keep your <code>package main</code> thin, and therefore have functionality that you want to unit test in sub packages.</p></pre>icholy: <pre><p>Lots of people call the <code>testdata</code> directory <code>fixtures</code></p></pre>b4ux1t3: <pre><p>I don&#39;t have an answer, and fortunately you seem to have found one.</p> <p>I just wanted to let you know that this was an excellent question, and actually helped me with a problem I&#39;ve been having. (Basically the same one you were having, only with pictures.) </p> <p>Thanks, OP, for being awesome. </p></pre>millerman101: <pre><p>No worries, don&#39;t forget to check out the other comments in this thread. Using an <code>io.reader</code> also seems like a useful way of approaching this problem.</p></pre>b4ux1t3: <pre><p>Yeah, that&#39;s what I&#39;m going to look at when I get back to my desk. </p> <p>I imagine there will be a similar type for binary files, but it&#39;s a good place to start. </p></pre>chzyer: <pre><p>I think that was ok, some official packages doing this in the same way: <a href="https://github.com/golang/net/blob/master/html/parse_test.go#L199" rel="nofollow">https://github.com/golang/net/blob/master/html/parse_test.go#L199</a> </p></pre>millerman101: <pre><p>I think so too, after researching more, using a directory called &#34;testdata/&#34; seems to be the best way. Seems that&#39;s how the go devs also go about testing with local files. </p> <p>Running</p> <pre><code>go help packages </code></pre> <p>also gives further information, including this piece here...</p> <blockquote> <p>Directory and file names that begin with &#34;.&#34; or &#34;_&#34; are ignored by the go tool, as are directories named &#34;testdata&#34;</p> </blockquote> <p>Thanks!</p></pre>thepciet: <pre><p>You can hard-code the equivalent of files, write files in the test and read them back then delete them, or just have testing files checked in.</p> <p>I mean, those are all basically the same unless you need to be generating computation data for the test. So it depends on your shop and application.</p></pre>schumacherfm: <pre><p>I&#39;m using <a href="https://github.com/spf13/afero" rel="nofollow">https://github.com/spf13/afero</a> for testing and avoid any contact with the disk.</p></pre>