It's been a while since this was posted. Hopefully the information in here is still useful to you (if it isn't please let me know!). If you want to get the new stuff as soon as it's out though, sign up to the mailing list below.Join the Mailing list
The next project in the pipeline is CasGo, an SSO server implementing the CAS protocol developed at Yale.
I decided to do this project in Go, as I didn’t have any large projects in Go yet, and have been reading a lot of literature and watching lots of videos about it. It seems to be fast becoming the perfect bridge between scripting and more traditional languages, perfect for use in lots of devops environments, and high performance/flexibility low-verbosity areas.
During my time using the language, I’ve really come to appreciate how much Go just gets out of your way. It’s got simple syntax and almost no syntactic sugar, and that makes for a really bare bones get-it-to-work programming experience that I really like. Since you can hold a lot of the language in your head, it’s very easy to sit and type out lots of useful code (refactoring along the way of course) that actually does what you want (and faster than in some other scripting languages).
However, despite how great Go is, the default testing package leaves a tiny bit to be desired (and it should, for fear of growing too big/including things that could be left to modules). Because of that, I’ve found that it was necessary to employ some libraries build to extend the testing package to write my tests.
Some of the issues that I was running into with the default testing package:
Also, with proper places to load/manage fixtures, I can get past some of my non-deterministic testing issues (I was doing a lot with the database, very quickly, and things would go wrong sporadically).
I am thorougly pleased with Ginkgo and Gomega, and am happily testing away!