setlist.fm API Go Wrapper

<p>Hey there guys, I&#39;ve spend the last weeks building an API wrapper for <a href="https://api.setlist.fm/docs/1.0/index.html">setlist.fm</a> and I&#39;d like some feedback!</p> <p>If you could check my <a href="https://github.com/jm-duarte/setlistfm">code</a> and guide me about what I could do better and what I did well would be amazing!</p> <hr/>**评论：**<br/><br/>CreativeCoconut: <pre><p>I just scanned over your projects for a little bit so I might have missed something.</p> <p>The first thing that jumped me when I looked at it is that you do not comment any of the exported methods. As this is an API wrapper which should be used by other programs this is rather important. I can get why you might not have seen the need for comments though as your method names are really clear and transport your intentions well, so props for that.</p> <p>Also regarding your filenames I suggest that you just call them datatypes.go and querytypes.go and leaving the underscore out. Generally it seems that underscores are only used for _test files or for architecture specific files such as _amd64. A question that refers to that on stackoverflow was [this one].(<a href="https://stackoverflow.com/questions/25161774/what-are-conventions-for-filenames-in-go" rel="nofollow">https://stackoverflow.com/questions/25161774/what-are-conventions-for-filenames-in-go</a>)</p> <p>A suggestion which might help you find standard things or shortcomings of your project might be <a href="https://goreportcard.com/report/github.com/jm-duarte/setlistfm" rel="nofollow">goreportcard</a> which uses the most common tools such as golint or go_vet to calculate a score for your projects. You are already doing pretty good there.</p></pre>CritJongUn: <pre><p>The comments are not forgotten! I was just trying to get it done first and worry about them later!</p> <p>I also know my tests are totaly lackluster but I have no idea how to unit test a huge JSON. If you can pinpoint me to some resources I&#39;d be grateful</p></pre>CreativeCoconut: <pre><p>I haven&#39;t really worked on JSON in Go yet but maybe the tests the guys from google wrote for their <a href="https://github.com/google/jsonapi" rel="nofollow">jsonapi</a> might help you a bit. </p> <p>I might take a look at it later tonight to figure it out as it seems like a nice practice and also a field I can learn something.</p> <p>Can you give me an example of such a huge JSON in maybe a pastebin or gist?</p> <p>Also, just cause I am curious, do you plan to open source that project? Maybe someone sees it here and likes the idea and just contributes to it by enhancing your tests, who knows. </p></pre>CritJongUn: <pre><p>It&#39;s in the readme, feel free to help! I&#39;ll give you an example later, on mobile rn</p></pre>CritJongUn: <pre><p><a href="https://api.setlist.fm/docs/1.0/resource__1.0_search_countries.html" rel="nofollow">JSON Example</a></p> <p>As you can see it can get pretty damn big, if you go back on the page and see others as well</p></pre>CreativeCoconut: <pre><p>I was thinking about it for a while and I might have misunderstood your question towards testing. Your issue is not that you do not know how to test JSON but that you do not know how to compare it with such a huge sample right?</p> <p>I don&#39;t know about setlist.fm enough but my last thought for this was that you might need some data which does not change or not very often for each test case and also have a copy of the expected result locally (maybe in some resource files) and then compare the results you get from setlist.fm with the data you already have locally. The data you have locally could be data you downloaded per hand or verified once as valid, so you know that, if the JSON you get in the test case is the same as you have locally, the data is valid.</p></pre>CritJongUn: <pre><p>Yes but the JSON string generated by the Go JSON lib is one-line, no tabs, newlines, whatsoever. And when I copy the JSON from Postman for example it comes with all that whitespace, so it won&#39;t be equal. Aaaand I just figured I can create a small script to clean the downloaded JSON to a &#34;pure&#34; string - no whitespace at all</p></pre>