Do you write unit tests to some straightforward API handlers like Create, Get, Update, Delete ?

<p>My question is if you&#39;re writing unit tests to obvious and straightforward handlers? Or are you leaving them to being tested in live/integration testing?</p> <p>Currently i&#39;m using Postman to fake frontend requests and i feel like i don&#39;t need to write unit tests for these handlers*.</p> <p>What&#39;s your opinion on this?</p> <p>*of course for now, i will write them eventually, when API become somewhat stable. It&#39;s just TDD can become very tiring when API is unstable.</p> <hr/>**评论：**<br/><br/>joncalhoun: <pre><p>If you want to think of this in programming terms, use this:</p> <pre><code>expectedCost := costIfError * probabilityOfError if expectedCost &gt; costToWriteTest { // Write a test! } else { // Probably don&#39;t need to write a test } </code></pre> <p>This obviously ignores the fact that errors can be reintroduced etc, but thats the basic idea. </p> <p>Writing tests for use cases that simply won&#39;t hurt you much is a waste of time. For example, if someone signs up with an invalid email address and your app returns a 500 status code instead of a 4xx, is it really a big issue? Sure, you might want to fix it eventually, but the user still has invalid data and chances are they&#39;ll still see an error message in the UI and figure out what is going on, so does this bug actually cost you much?</p> <p>On the other hand, bugs where you might lose sales could be a much bigger issue and might require many more tests to ensure they don&#39;t happen, so perhaps you want to test your <code>Create</code> for orders and shopping carts a little more thoroughly than your <code>Create</code> for your user resource.</p> <p><em>ps - yes I get that failing ot create an account might also lose sales, but this is a contrived example. every app is different</em></p></pre>epiris: <pre><p>I usually write a test for every handler and each middleware, it’s pretty low cost copy paste. Even if it may not catch many issues while writing the code, it makes it easier to come back to in N months and drop in a new feature without any regressions.</p></pre>boompleetz: <pre><p>Sure, just small ones, why not?</p></pre>titpetric: <pre><p>I think your question is dealing with two types of tests</p> <ul> <li>internal (unit tests)</li> <li>external (integration test, e2e tests,...)</li> </ul> <p>It is important to automate testing, so I don&#39;t think using Postman by hand to issue requests is good enough. A change in your application might reasonably produce unexpected changes in various API endpoints, and having an automated way to check validity is priceless.</p> <p>Write those few unit tests which are absolutely required, preferably sooner than later. If you think TDD is tiring, then most likely you&#39;re not dedicating enough time to planning your development. Most unit tests that are written should only be written once, and adjusted for changes in specifications.</p></pre>kerakk19: <pre><p>But Postman is able to do automate testing and it&#39;s pretty simple to set up.</p></pre>shovelpost: <pre><p>It&#39;s even better to have your tests be part of your code.</p></pre>titpetric: <pre><p>Good enough, I asumed it was just some sort of web console to issue api requests by hand.</p></pre>r-_3: <pre><p>it depends on how you write servers.</p> <p>You can easily write a helper function that can make testing easier, you can consider that what you&#39;re testing is the status code returned from a handler.</p> <pre><code>testHelper(t* testing.T,request *http.Request, server http.Handler, status int) </code></pre> <p>and then just use a for loop to tests your requests in series.</p> <p>If you need to test more things, you can just emulate a union type instead of a status</p> <pre><code>type ExpectType byte const ( Code = iota Custom ) // union type UExpect struct { // will default to Code ExpectType Code int Func func(httptest.ResponseRecorder)error } testHelper(t* testing.T,request *http.Request, server http.Handler, e UExpect) // usage testHelper(t,request,server,UExpect{ExpectType:Custom, Func:func(r httptest.ResponseRecorder){ // check some headers or the body here }) </code></pre> <p>Go isn&#39;t JS or Ruby but there are still ways to save time while not cutting corners on code quality. Now if go had variant types and method overload like Ada ...</p></pre>HugoWeb: <pre><p>No, I just test the APIs afterwards in a big ole test functions which runs when I pass --test to my app...</p></pre>0xor1: <pre><p>It&#39;s up to you there is no right answer, you never have to write any unit tests at all if you don&#39;t want, but typically is a good idea to give some insurance against breaking changes in future</p></pre>