<p>Hey, I wrote a instamojo API Wrapper in golang. Take a look here, <a href="https://github.com/ishanjain28/instamojo" rel="nofollow">https://github.com/ishanjain28/instamojo</a></p>
<p>Documentation: <a href="https://godoc.org/github.com/ishanjain28/instamojo" rel="nofollow">https://godoc.org/github.com/ishanjain28/instamojo</a></p>
<p>Please let me know if you have any suggestion/criticism or advice.</p>
<hr/>**评论：**<br/><br/>shovelpost: <pre><p>Here's a few things you can fix: <a href="https://goreportcard.com/report/github.com/ishanjain28/instamojo" rel="nofollow">https://goreportcard.com/report/github.com/ishanjain28/instamojo</a></p>
<p>You really need to write tests, ideally both Unit tests and integration tests that call the live API.</p>
<p>I'd also suggest to improve the documentation. Preferably instead of just linking to the godoc and call it a day, you could have the documentation directly in the readme.</p>
<p>I mean there's nothing wrong with a link to godoc but when I went to godoc to read the documentation I had only this line to read: </p>
<blockquote>
<p>"Package instamojo aims to provide a Wrapper for instamojo.com's API It is a work in progress and all remaining endpoints shall be added soon"</p>
</blockquote>
<p>You need to make the usage of the package more obvious for the end user. A great way to do that is with <a href="https://blog.golang.org/examples" rel="nofollow">testable examples</a>.</p></pre>ishanjain28: <pre><p>Examples, Tests and some documentation on github as well. Got it. </p>
<p>Calling their API requires tokens, But I can't really put my tokens in the test files. </p>
<p>Thanks for your input. </p></pre>shovelpost: <pre><blockquote>
<p>Calling their API requires tokens, But I can't really put my tokens in the test files.</p>
</blockquote>
<p>No you can't. But since these are integration tests anyways, you can use the flag package and receive them as input. If the person that tries to run the integration tests does not provide the flags, you just fail the tests and exit with a friendly message that shows what flags should be used.</p></pre>ishanjain28: <pre><p>Yes, I can definitely do that. I am now writing tests and examples for it. Thank you so much.</p></pre>puffybunion: <pre><p>How come you chose to make <code>Config</code> the object which makes requests?</p>
<p>I'd assume it would be something like <code>Client</code> which accepts a <code>Config</code> upon initialization.</p>
<p>Another thing I find useful is making your <code>Config</code> (or <code>Client</code>) an interface so that it can be mocked by others using your library.</p></pre>ishanjain28: <pre><p>Yes. I figured it would be useful to use a interface instead of a struct when I was writing tests. </p>
<p>But I still don't know if I should use httpmock to mock instamojo api or use a fake makeRequest method</p>
<p>I thought a bit about the second option but I don't know how to implement that.</p></pre>puffybunion: <pre><p>I'm not sure I understand the second option.</p>
<p>But for the first, there is a trick I like to use to mock external APIs:</p>
<pre><code>type Doer interface {
Do(req *http.Request) (*http.Response, error)
}
</code></pre>
<p>This interface is implemented by <code>http.Client</code>, so if your <code>InstamojoClient</code> takes a <code>Doer</code> to make all of it's http requests, you can easily provide it with a mock <code>Doer</code> that returns whatever you'd expect the actual API to return.</p>
<p>Not sure whether this is better then <code>httpmock</code> or not.</p></pre>
