What is your api testing workflow for web apps in Golang?

<p>Recently discovered a long running bug in a project I work on. I&#39;d like to set up some monitoring either at build time or on the live api, to verify that each route is doing what its supposed to do. I have limited experience with testing so I&#39;m wondering what a good test workflow looks like. Unit testing code that touches the database / api routes is kind of a nightmare so I&#39;m thinking of using integration tests system wide. Any one here have experience / knowledge I can lean on?</p> <hr/>**评论：**<br/><br/>goenning: <pre><p>Integration test is great to start when you have working code that might not fit into a unit test (yet). But on the long term you should aim for unit test as they are much faster and less flacky.</p> <p>I have very clear separation of responsibilities of my packages, so everything that doesn’t do any IO I write unit tests, eg.: http handlers. The handlers itself depend on a “storage” interface, that always has two implementations: inmemory or postgres. During unit tests I use the in memory storage.</p> <p>Because the postgres storage interact with database, to be sure they work as expected, I write integration test, but that’s very specific to these functions/structs.</p> <p>The last step is my e2e, which uses Selenium to test my application from a user point of view. This is the hardest test to setup and the most likely to fail. I try to avoid them and focus on Unit and Integration, but a few e2e are very helpful!</p></pre>burnaftertweeting: <pre><p>Can you tell me more about your storage interface? I tried doing something similar for a mysql database but failed miserably. Simple queries aren&#39;t too bad but the more complex don&#39;t seem to fit the mold of a wrapper style approach well. Any tips?</p></pre>goenning: <pre><p>My storage actions are not complex as well, so I didn’t have any issues. You can check it out here <a href="https://github.com/getfider/fider/tree/master/app/storage" rel="nofollow">https://github.com/getfider/fider/tree/master/app/storage</a></p> <p>storage.go has the interface and those packages the implementation.</p> <p>Tests against the postgres storage runs against a Docker instance, each test cleans up the database and seed with well known data so that the tests always start with a predictable state.</p></pre>fortytw2: <pre><p>Check out how <a href="https://github.com/fortytw2/hydrocarbon/blob/master/db_test.go" rel="nofollow">https://github.com/fortytw2/hydrocarbon/blob/master/db_test.go</a> works - all the db tests are done directly against a live postgres, spun up inside a new docker container every time. However, there are still interfaces in front of each set of handlers so they can be tested with OR without the DB. (see <a href="https://github.com/fortytw2/hydrocarbon/blob/master/user_api.go#L22" rel="nofollow">https://github.com/fortytw2/hydrocarbon/blob/master/user_api.go#L22</a> )</p> <p>Entire test suite here takes ~8s on my fanless laptop, no worries about speed w/ docker. Project pretty heavily leverages the database, so mocking everything out is a bit stupid for my purposes (doesn&#39;t actually provide anything useful besides an increased coverage %)</p></pre>burnaftertweeting: <pre><p>Awesome thanks! So, rather than mock the database, you&#39;re throwing up a containerized database during test. Brilliant.</p></pre>fortytw2: <pre><p>Has the plus side of making it really easy to ensure all your queries are syntactically valid / return what you expect. I like to think of it as making integration tests so easy / fast to run that you don&#39;t even need to bother with testing in isolation of the db</p></pre>sjkaliski: <pre><p>We recently open sourced this project <a href="https://github.com/beme/abide" rel="nofollow">https://github.com/beme/abide</a>. We use it capture &#34;snapshots&#34; of our API responses, which subsequent tests compare against. That way, if we make a change anywhere in our API and it &#34;breaks&#34; the response we expect, we&#39;re alerted.</p> <p>It also keeps the snapshots in version control which helps keep track of how our API changes over time.</p></pre>devmarwen: <pre><p>Personally I use Ginkgo coupled with Httpexpect for controllers specs and really enjoying it. Find it even better that Rspec for Rails.</p></pre>burnaftertweeting: <pre><p>Httpexpect looks promising, I&#39;m not sure I understand enough about BDD to use Ginkgo.</p></pre>