Database unit tests with mgo anyone?

<p>I&#39;m learning how to do some <em>integration</em> tests with mgo using a temporary mock database following the example from this <a href="https://medium.com/@mvmaasakkers/writing-integration-tests-with-mongodb-support-231580a566cd" rel="nofollow">article</a> however I keep getting &#34;panic: timeout waiting for mongod process to die&#34; caused by calling Stop() method on dbtest.DBServer. As a result after running the test I&#39;m left with an idle mongod process running in the background. Is there something I&#39;m missing?</p> <hr/>**评论：**<br/><br/>comrade_donkey: <pre><p>So a couple of things.</p> <ul> <li>Don&#39;t trust an article that doesn&#39;t even get the name of the programming language right. It&#39;s &#34;Go&#34;, not &#34;GO&#34; nor &#34;GOlang&#34; or &#34;Golang&#34;.</li> <li>You don&#39;t unit-test your database, you just don&#39;t. You unit-test your functional units.</li> <li>Your tests should be self-contained. You can&#39;t expect to have someone running mongodb on their machine just to run the tests.</li> <li>Mock out the database by writing a FAKE database session, not a &#34;real mock database&#34;, that&#39;s not a thing. Testable code depends on interfaces, mock those interfaces.</li> </ul> <p>PS: did you notice the article is about <strong>integration</strong> tests and not unit tests?</p></pre>emelent: <pre><p>Hmmm, then what&#39;s the point of dbtest if not to make these temporary db&#39;s? Also, wouldn&#39;t mocking the whole mgo.Session be overkill? I mean wouldn&#39;t that mean I&#39;d have to mock all the methods I use on the session, either that or check if it&#39;s a real dbsession or mock dbsession and act accordingly?</p></pre>comrade_donkey: <pre><blockquote> <p>what&#39;s the point of dbtest</p> </blockquote> <p>It&#39;s an integration test for the <code>mgo</code> driver itself.</p> <blockquote> <p>wouldn&#39;t mocking the whole mgo.Session be overkill?</p> </blockquote> <p>Probably. It&#39;s also difficult to get every edge case exactly identical. Thankfully, you don&#39;t need to mock the entire session. You just need to mock the interfaces your code depends on. In most cases, that just create, read, update &amp; delete. If that&#39;s not the case, then the first step would be to read about separation of concerns, information hiding, command/query segregation, etc. It&#39;s not easy to write testable code.</p></pre>emelent: <pre><p>I guess I&#39;ll read more on this, thanks for your input.</p></pre>