Test helper for building fake environment configs.

Test helper for building fake environment configs.

The config tests in both the ec2 and openstack environment provider repeat the same code to set up and verify environment configs.  With MAAS we're about to add another use.  And so in this branch I extract a part of this code that is not specific to a given provider.

An alternative would have been to cargo-cult yet another copy of this code and write similar data-driven tests, but with this much code inbetween and this little documentation, it's not clear what the meaning of those tests would be or what coverage is.

https://code.launchpad.net/~jtv/juju-core/config-test-helper/+merge/146059

(do not edit description out of merge proposal)

[jtv.canonical, 2013-02-01 11:54:17]

Please take a look.

[dimitern, 2013-02-01 12:04:17]

Very nice, LGTM! I'd like to see more of the common code refactored across
providers eventually.

[TheMue, 2013-02-01 12:19:21]

LGTM, will help me with the local provider too.

[rog, 2013-02-01 17:52:19]

i'm not sure about this. i think that most of the code that's factored out is
unnecessary. i've made an alternative CL that simplifies the code in both
places, hopefully reducing the cargo-cult nature of the code and reducing the
usefulness of factoring out the common code.

alternative CL: https://codereview.appspot.com/7231080

https://codereview.appspot.com/7225082/diff/5001/environs/testing/config.go
File environs/testing/config.go (right):

https://codereview.appspot.com/7225082/diff/5001/environs/testing/config.go#n...
environs/testing/config.go:1: package testing
i'm not sure this justifies yet another testing package.
we already have environs/jujutest - this can probably live quite happily there.

[jtv.canonical, 2013-02-04 03:55:10]

As John also pointed out, I think you're removing test coverage — although of
course given the poor commenting of the original code it's hard to say what the
intent was.

It looks to me as if the roundtrip should have been a separate test and could
have been run just once.  I'll try writing it up that way.  We must get the
duplication under control in any event, because we're talking about 4 instances
of the same testing support now.

Having yet another testing package is unfortunate, but it seems to be the Go
way.  The jujutest package seems to be specifically for testing against a real
server.