What are the best practices to unit test a webserver?

<p>I have a todo list manager, I want to know what are the best practices to do unit testing, just testing http handlers? status codes?</p> <hr/>**评论：**<br/><br/>nstratos: <pre><p>Check out these:</p> <ul> <li><a href="https://talks.golang.org/2014/testing.slide">https://talks.golang.org/2014/testing.slide</a></li> <li><a href="https://golang.org/pkg/net/http/httptest/">https://golang.org/pkg/net/http/httptest/</a></li> </ul></pre>thewhitetulip: <pre><p>I&#39;ll go through the links. Thank you.</p></pre>natdm: <pre><p>Where I work, we also use testify mocks, if you have services. So you don&#39;t have to mock an entire database out, you can do something like mockDatabase.On(&#39;GetUser&#39;, p1, p2).Return(nil, sql.ErrNoRows)</p> <p>Then test your code on what it will do when it gets an errNoRows from SQL.</p> <p>We use mockery to generate the mocks of interfaces.</p> <p>This obviously means sending sometimes huge interfaces around to mock things out, but it&#39;s a decent price to pay for testability.</p></pre>thewhitetulip: <pre><p>As of now I am just using Sqlite, so I can mock an entire database for each unit test. Yes, not having to mock an entire database seems nice. It would be great if you can write a blog post about the same.</p></pre>dAnjou: <pre><p>Please realize that <em>unit</em> tests are just one kind of tests. There are also other tests, most of which have some tools or frameworks to help you.</p> <p>A unit test tests only a very limited logical unit like for example a function replacing all whitespaces in a string with an underscore.</p></pre>thewhitetulip: <pre><p>Valid point, my question itself was invalid. I can&#39;t change it now!</p> <p>Let me rephrase the question, &#34;What are the best practices to test a webserver or API?&#34;</p></pre>kpurdon: <pre><p>I&#39;ve been working through this myself and have found that unit testing http handlers is often not all that useful.</p> <p>IMO</p> <p>Unit tests are good for things where you have little interaction outside of the function (like a test to check valid formats of some thing). But when it comes to http API testing integration/acceptance testing are king.</p> <p>I&#39;ve landed on the following solution.</p> <ol> <li>I use <a href="https://github.com/DATA-DOG/go-txdb" rel="nofollow">https://github.com/DATA-DOG/go-txdb</a> to create a single-transaction during my test so that data is not leaked out of a test run.</li> <li>Each test does it&#39;s own setup (creating things, deleting things) and then runs through test cases.</li> </ol> <p>So lets say I have some generic resource <code>{&#34;foo&#34;: [{&#34;bar&#34;}]}</code> that I expect back from an endpoint. The test would be:</p> <ul> <li>create txdb</li> <li>get foo via handler (see nothing, assuming a fresh test-db)</li> <li>setup: insert a foo into the db directly</li> <li>get foo via handler (see the inserted result)</li> <li>cleanup: remove foo from db directly</li> <li>txdb does it&#39;s magic and reverts the transaction</li> </ul></pre>thewhitetulip: <pre><p>Thank you. I have a different thought, how about creating an entirely new database for the test case?</p> <p>After all this is an API is just going to call a db method to insert or update or delete or fetch. Is it wise to spawn a new db, have a table driven test for insertion, after each insert, fetch the count and the values if you like, if not okay, then problem, else it&#39;s okay.</p> <p>Later, checking the json returned by the handlers?</p></pre>neoasterisk: <pre><p>This is what I do. Those are not really unit tests though. They are more or less integration tests. I write those tests as normal and I guard them with build tags since they hit a real database and take longer. So I have to write something like <code>go test -tags=integration</code> to call them. </p> <p>I really like this pattern. Besides If I do all this effort to make my code support an in memory database, I might as well test against the real database.</p></pre>thewhitetulip: <pre><p>Okay, so I should tag my tests, test against a mock db and an actual db.</p> <p>Thank you :-)</p></pre>