[Beginner] How do you usually write test for large systems?

<p>What are some tips for beginner that is spoiled by functional programming?</p> <p>My last internship was primarily scala, and writing test in pure functional style is easy (input-&gt;output), my current internship use golang, while writing it is very easy like python I find that testing it is hard (lots of side effect).</p> <p>I am writing test for legacy right now, and its overwhelming.</p> <p>Channel passing message everywhere, mutating state is very common.</p> <p>So I was wondering if there are any tips for beginner in writing test or design large system in general.</p> <hr/>**评论：**<br/><br/>jeffrallen: <pre><p>Code that is hard to test is trying to tell you that it wants to be rewritten to separate out concerns so that they can be tested separately.</p> <p>Find out what is core to a routine, and what it depends on. Replace the thing it depends on with a mock who&#39;s state your test controls. Then you can test the core of the routine, without worrying about the rest of the side effects on the system.</p> <p>For example, func (c *config)dump(filename string) is hard to test because it wants to actually write onto disk. Instead, change it to take an io.Writer as it&#39;s arg. In production code, the caller will do os.OpenFile to get the io.Writer to the new file. In your test code, you&#39;ll use a bytes.Buffer, which is also an io.Writer. then you will look in the buffer to see if the config file is what you expected it to be.</p> <p>-jeff</p></pre>tech_tuna: <pre><p>This is excellent advice, however some level of contract/system testing is also good and augments a solid unit test environment. You want to make sure that Team A never breaks an API contract for Team B and vice versa.</p></pre>: <pre><p>[deleted]</p></pre>tech_tuna: <pre><p>Excellent point, a dev team that doesn&#39;t take testability into account and write tests from day one, is one destined to amass a megaton of technical debt. FWIW, this is still pretty common based on what I&#39;ve seen with my full time work and side consulting.</p></pre>nagai: <pre><p>Addressing your problem of having lots of side effects - using interfaces to mock out components in tests is a really central technique to testing in Golang.</p> <p>To get an idea, see <a href="https://nathanleclaire.com/blog/2015/10/10/interfaces-and-composition-for-effective-unit-testing-in-golang/" rel="nofollow">this article</a> for instance.</p></pre>jerf: <pre><p>As <a href="/u/nagai" rel="nofollow">/u/nagai</a> points out, use interfaces to mock out bits of the code. I <a href="http://www.jerf.org/iri/post/2923" rel="nofollow">wrote about how this enables a loose form of parametricity</a> a while back. You should also be able to use this to improve the testability of the code; the pattern of &#34;complicated one-time setup -&gt; simple recurring usage&#34; in one function is very common, and very easy to break into two pieces so the simple recurring usage can be tested.</p> <p>Also, all channels are also automatically &#34;mocked&#34;, if you can redirect the appropriate end into your test code. There is nothing wrong with refactoring some code that creates a channel on the stack to one that creates it in a struct and gives the test code a chance to change it or use it.</p> <p>All in all, after a lot of functional experience, I have found Go to be wonderfully easy to test in my own code, with relatively small amounts of attention paid to using certain techniques to make it easy. And those techniques are almost without exception quite cheap, or even of negative cost (i.e., they&#39;re also the right thing to do in the medium to long term anyhow), once you get used to them.</p></pre>