How to integration test the DAO layer in Go?

<p>Are there any recommendations on how to integration test the DAO layer in a Go program? I&#39;ve seen lots of ways to test the code that depends on the DAO layer - using Interfaces being the prime one - but nothing about testing the DAO layer itself.</p> <p>Of particular concern is doing it in a way that works in a CI system such as Travis or Shippable, where the entire test system is clean for every build. This means that just having the database engine running and ready isn&#39;t an option.</p> <p>In my Java code I&#39;ve always done this using an &#34;Embedded&#34; database - there is a Java module that literally just downloads Postgres, starts it up, and then at the end of the run shuts it down and deletes it all - but I&#39;m not sure of anything like this for Go?</p> <p>Essentially I&#39;m after:</p> <ul> <li>Ability to run something that resembles the real database closely enough (Either by actually being the real database, or by somehow responding to queries correctly)</li> <li>Ability to completely reset the data in the database between tests (I can do that manually as long as I can connect to the database from the tests too)</li> <li>Ability to set up the schema in the database before the tests run - assuming it&#39;s a real database and not a set of well behaving mocks</li> <li>No need to install anything on the system manually beforehand, because that&#39;s not an option on the CI platform (It uses a clean Docker image for every run)</li> </ul> <p>Cheers</p> <hr/>**评论：**<br/><br/>tmornini: <pre><p>Mock the sql package through dependency injection then test that the correct SQL is sent.</p> <p>There’s zero benefit to actually touch a DB for unit tests — your integration tests should handle that — and should run from a “clean” database in any case.</p></pre>jns111: <pre><p>For the sql package I&#39;m using this: <a href="https://github.com/DATA-DOG/go-sqlmock" rel="nofollow">https://github.com/DATA-DOG/go-sqlmock</a> Works like a charm. Of course this doesn&#39;t end to end test the interaction with a database but this is another story. In case the DAO works 100% as expected the only thing you need to verify together with a real database is if the db schema exactly reflects what your were testing with the unit tests.</p></pre>sazzer: <pre><p>Not quite the only thing. Also need to prove that the queries being executed are correct - it&#39;s easily done that they aren&#39;t and you don&#39;t find out until too late. However, this looks very helpful. Thank you :-)</p></pre>edwinTop: <pre><p>I use Godog for this , it&#39;s very simple to setup, I&#39;d usually follow this pattern in my ci pipeline: </p> <ul> <li>spin up docker containers for e.g postgres</li> <li>run schema migrations , seed data if needed </li> <li>run th Go binary of my app, passing the spinner docker database connectionstring as env </li> <li>invoke Godog to run my integration tests</li> <li>destroy db container even though tests pass or fail </li> </ul> <p><a href="https://github.com/DATA-DOG/godog" rel="nofollow">https://github.com/DATA-DOG/godog</a></p> <p>CI i use is concourse but should be able to use any other ci that supports docker I guess</p></pre>sagikazarmark: <pre><p>I do something very similar, but in my case I made the CLI layer so small that I start the application itself from the godog run in a before hook. I was also able to pack everything into regular go tests, so my acceptance tests run as part of the go test invocation.</p></pre>edwinTop: <pre><p>Wow awesome ! Is code open-source? will like to see how you structured stuffs there </p></pre>Ribice: <pre><p>I use this: <a href="https://github.com/ory/dockertest" rel="nofollow">https://github.com/ory/dockertest</a></p> <p>Works like a charm. An example is available here: <a href="https://github.com/ribice/gorsk" rel="nofollow">https://github.com/ribice/gorsk</a></p></pre>adelowo: <pre><p>Like <a href="/u/tmornini" rel="nofollow">u/tmornini</a> said mock dependencies but make sure you actually have integration tests that hit the database. I have used drone ci and goose successfully for this (MySQL though, shouldn’t matter). </p> <p>A container is started before the tests run , before each test case, I run goose to perform the database migrations, then have something like defer teardown which “Drops” the database..</p></pre>quiI: <pre><p>I would look to utilise docker-compose in your CI setup personally. In the long run, being able to spin up your DB for running tests will be easier. Docker makes this all lightweight and easy and then it means you dont need to bring in special libraries or whatever. </p></pre>FullTimePhilosopher: <pre><p>What about testfixtures?: <a href="https://github.com/go-testfixtures/testfixtures" rel="nofollow">https://github.com/go-testfixtures/testfixtures</a></p> <p>You have to use it together with a migration library, though.</p> <p>The idea is: you use a migration library to either create the schema in a clean database (CI) or make an existing one up-to-date. Then you use testfixtures to clean and load fixtures before each test run.</p> <p>This kind of mimic how Ruby on Rails deals with tests.</p></pre>sazzer: <pre><p>This combined with dockertest that was mentioned elsewhere seems like it&#39;s got a lot of potential :-)</p></pre>