What tools do you use to test database interactions in Golang?

<p>I&#39;m really enjoying learning Go, but the testing side of things is giving me a bit of pause. I&#39;m more used to things like Ruby where there are &#34;magic&#34; testing tools to replace databases with imaginary ones based on a schema and figuring out how to test databases in a straightforward way is proving tricky. If anyone can offer me some tips I would be really grateful.</p> <p>Right now, I&#39;m thinking that I&#39;d ship with my tests a SQL file that creates a database from scratch and populates it with good information, then run a query on it to update/add data, run a select to check that the data is as expected, then destroy the database.</p> <p>But I can see that approach having a lot of problems. It requires the dev environment to have a DB server running, for one. More importantly, I wouldn&#39;t want bad data added in one test to ruin an unrelated test and show misleading errors, so each test should get its own fresh copy of the DB, and that&#39;s going to be really limiting/expensive/enforce them to be run sequentially. </p> <p>I&#39;m looking at the library <a href="https://godoc.org/github.com/DATA-DOG/go-sqlmock" rel="nofollow">sqlMock</a> which seems mature and fairly popular, but I don&#39;t know if it&#39;s exactly what I&#39;m looking for. Any advice on workflows for this sort of thing?</p> <p>Worth noting: I do know that mocking your DB isn&#39;t good for integration tests, and that working with a real database should be tested at some point too. But right now I want to have a quick-feedback test while developing new features. I want to write a ton of small, fast tests for every specific database-affecting/selecting feature that I can run over and over as I code, and then after that I&#39;ll add a few bigger thorough integration tests with a real DB that I&#39;ll run more occasionally just to make sure nothing&#39;s broken.</p> <hr/>**评论：**<br/><br/>l3pp4rd: <pre><p>Hi, I&#39;m the author of sqlmock, which is meant to be used for unit tests only to test all critical paths possible for certain logic. But you should also have integration tests using your real database and for that.</p> <p>I have also built <a href="https://github.com/DATA-DOG/go-txdb" rel="nofollow">https://github.com/DATA-DOG/go-txdb</a> which in general makes a database connection perform within a single transaction. That means, if you setup a database, all your tests will execute within transaction, when database is closed, transaction is rolledback. For that reason, all tests execute very fast and for every test you can have a clean isolated state.</p> <p>Also for integration tests, there is BDD framework - cucumber <a href="https://github.com/DATA-DOG/godog" rel="nofollow">https://github.com/DATA-DOG/godog</a>.</p> <p>All these tools are usually my daily stack for testing purposes. I also make randomized brute force like tests (which for example generates random data and performs assertions for a certain run period), since you will never find all edge cases in your unit or integration tests.</p></pre>j_d_q: <pre><p>I use sqlite with an in-memory database for unit tests</p> <p>For integration tests we attach a MySQL container (or postgres or a matrix if it needs to support several)</p></pre>shovelpost: <pre><blockquote> <p>so each test should get its own fresh copy of the DB, and that&#39;s going to be really limiting/expensive/enforce them to be run sequentially.</p> </blockquote> <p>It has been surprisingly fast for me. I highly recommend this approach.</p></pre>Franke123: <pre><p>We use Docker to spin up a PostgreSQL container for testing. Tests still run relatively fast and it&#39;s easy to setup for running on a dev machine and on travis.</p></pre>