How to write unit tests for a client side go package?

<p>Hi all, </p> <p>I&#39;m currently making a <a href="https://github.com/sirkaiserkai/go-diawi/tree/master" rel="nofollow">package</a> that wraps the client functionality for a web service called <a href="https://www.diawi.com/" rel="nofollow">diawi</a>. For background, diawi&#39;s is a hosting site for mobile apps in development or to be released to a limited audience (Such as testers, clients, etc). </p> <p>I&#39;ve completed most of the package and want to begin writing tests for all the functionality and I&#39;ve hit a (mental) road block, how exactly should I write tests for a client side of a web service? </p> <p>Looking at upload_test.go</p> <pre><code>package godiawi import ( &#34;testing&#34; ) func TestUploadSuccess(t *testing.T) { ur := UploadRequest(Token: &#34;APIToken&#34;, File: &#34;app.ip&#34;} uploadResponse, err := ur.upload() if err != nil { t.Errorf(&#34;Error: %s&#34;, err) } if uploadResponse.status != Ok { t.Errorf(&#34;Failed to upload app) } } </code></pre> <p>Would this be a bad design since this is dependent on the web service? Since if errors or issues are occurring on diawi&#39;s side, it would then report a false-negative in the test cases.</p> <p>I would like to avoid this but what is the recommended way of making the tests deterministic? </p> <hr/>**评论：**<br/><br/>fvosberg: <pre><p>I usually do this by first, writing tests against the third party service which consist of more or less a request/expected response pair. This tests I just have to execute while writing it and in the future to verify the API hasn&#39;t changed. After that, I write a mock for the external service and use the same tested pairs of request/response. This mock is ready to be used in your test. But that trades only off, when the client itself has logic, I think. You can&#39;t test that an external service has not changed it&#39;s behavior without relying on it&#39;s availability</p></pre>fvosberg: <pre><p>Another good way I&#39;ve found is this recorder: <a href="https://github.com/seborama/govcr" rel="nofollow">https://github.com/seborama/govcr</a> I didn&#39;t use it yet, but it looks like the thing you need, doesn&#39;t it?</p></pre>adelowo: <pre><p>You should make use of the request recorder <a href="https://godoc.org/net/http/httptest#ResponseRecorder" rel="nofollow">https://godoc.org/net/http/httptest#ResponseRecorder</a></p></pre>sethammons: <pre><p>Have the client to diawi adhere to an interface. Then you use a fake that adheres to the interface in your tests. You can now test your code against errors and happy path from diawi. Like you said, you don&#39;t want to be in a false-negative situation depending on their ability to serve your request. At least, not at the unit level. For integration testing, I think it is fine to make a real call to their service, but this is something that should happen at the end of testing, before deployment.</p></pre>bigpigfoot: <pre><p>you should just test your requests (for client) and responses (for server), then proceed to integration tests.</p> <p>for example, I&#39;d do </p> <pre><code>func TestUploadRequest(t *testing.T) { req, err := client.UploadRequest(params) if err != nil { t.Error(err) } assert(req) } </code></pre></pre>puffybunion: <pre><p>Like others have said - you can just use ResponseRecorder.</p> <p>Another option is mocking an http.Client by defining a Doer/Client interface: <a href="https://play.golang.org/p/P8fFoC58Cg" rel="nofollow">https://play.golang.org/p/P8fFoC58Cg</a></p></pre>