Go Testing Toolbox: from Autotest to Vagrant(nathany.com)
nathany.com
Go Testing Toolbox: from Autotest to Vagrant
http://nathany.com/go-testing-toolbox/
2 comments
We improved our Go support on Codeship (https://codeship.io, I am one of the founders) over the last couple of days. Give it a try and if you have questions let me know.
So testing double(mocking) in Go is still a big headache in version 1.2?
So testing double(mocking) in Go is still a big headache
in version 1.2?
Someone on the Go Nuts mailing list asked for an example of mocking with interfaces, so I quickly wrote up this:
http://play.golang.org/p/9JUvbeBTAY
http://play.golang.org/p/9JUvbeBTAY
Mocking is always a problem if the code wasn't written with testing in mind, regardless of the language.
Dynamic languages, make such cases a bit less painful, because you can go in and override the code.
Static languages with bytecode generation also allow for some workarounds, with help of frameworks that rewrite bytecode.
With generated native code, things get really ungly when trying to rewrite the generated machine code.
So in the end, things are way much simpler if the code allows for testing.
Dynamic languages, make such cases a bit less painful, because you can go in and override the code.
Static languages with bytecode generation also allow for some workarounds, with help of frameworks that rewrite bytecode.
With generated native code, things get really ungly when trying to rewrite the generated machine code.
So in the end, things are way much simpler if the code allows for testing.