This is one aspect of the MIR of Go, juju, and its libraries from bug 1267393.
In comment 86 the MIR team requested testing buildability of reverse Go dependencies when a library changes. A synthesized autopkgtest for those is trivial, something like
Test-Command: true
Restrictions: build-needed
This will build the package against the proposed dependency and install all of its binaries. There's no actual test (just "true"); if there is a way to test libraries/packages in a generic way, this should be done instead of "true"; you can look at the existing ones for Perl/Ruby/DKMS in http://anonscm.debian.org/cgit/collab-maint/autodep8.git/tree/support (check the "generate" scripts). This assumes that Go library packages already run their upstream tests during package build; if that's not the case, then this is certainly a must for running in autopkgtest at least.
The other thing that we need is an algorithm to detect a go library/package as such, i. e. some properties of the unpackaged source tree which tells autopkgtest that the synthesized test is applicable to it. Again you can look at the "detect" scripts in the above autodep8 tree to see how it's done for Perl and friends.
Note that these tests should preferably also work for stable releases. We just use one autodep8 install for all Ubuntu releases, so if you need any helper scripts in binary packages, or some tests don't apply to earlier Ubuntu releases, the detect script should preferably account for that. If it doesn't, tests will just go into "always failed" for earlier releases, which isn't an actual problem, but may look confusing.