Merge lp:~jtv/gwacl/list-images into lp:gwacl
Status: | Merged |
---|---|
Approved by: | Jeroen T. Vermeulen |
Approved revision: | 92 |
Merged at revision: | 85 |
Proposed branch: | lp:~jtv/gwacl/list-images |
Merge into: | lp:gwacl |
Diff against target: |
185 lines (+141/-2) 4 files modified
managementapi.go (+14/-0) managementapi_test.go (+83/-0) test_helpers.go (+2/-2) xmlobjects.go (+42/-0) |
To merge this branch: | bzr merge lp:~jtv/gwacl/list-images |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Julian Edwards (community) | Approve | ||
Review via email: mp+156329@code.launchpad.net |
Commit message
Support listing of OS images.
Description of the change
I kept XML annotations minimal: we've been listing the XML tag names but they're optional where identical to the names of their respective struct fields. I continued our tradition of upper-casing acronyms in the struct names even if Microsoft sometimes (but not always!) writes them in mixed case. I may write up a separate branch ensuring consistency, so that we'll always capitalize these fields in a predictable way — even if we're not actually consistent with Microsoft's spelling.
For testing I went with a different approach than we've been doing: one test verifies that the function makes the expected request, and another verifies the call's outcome. I think that ends up being much easier to read than a flurry of checks at the end to assert very different aspects of what happened. Concentrating the tests into big "check everything the way I usually do" functions reduces check size but makes it harder to follow what is being checked where, or how to add new checks. It also harms flexibility.
What we see at work here is the old "big tests attract more code" antipattern. It's caused by expensive test setup, and by a lack of dependency injection forcing the unit-testing into integration-style tests. Go forces these styles on us, but I reduced test setup *per test* slightly in that now I only need to rig one fake dispatcher per test, with each serving a more specific goal.
Jeroen
Nice change! There's quite a few niggling bits to change I think so I marked it needs fixing so I can take another look later.
8 +// ListOSImages retrieves the list of available operating system disk images
9 +// from the Azure management API.
10 +// Images are returned in the order in which Azure lists them.
11 +func (api *ManagementAPI) ListOSImages() ([]OSImage, error)
Can you please get into the habit of adding the URL to the Azure API reference in the comments for these exported API methods. It'll really help newcomers understand what it's doing, and help maintainers fix bugs quicker!
45 +func (suite *managementAPIS uite) TestListOSImage sReturnsImages( c *C) { storage. example. com/12345"
46 + const (
47 + logicalSize = 199.0
48 + label = "osimagelabel"
49 + mediaLink = "http://
50 + name = "imagename"
51 + eula = "firstborn.txt"
52 + description = "Description."
53 + )
I don't find this const section useful at all, FWIW. I'd just throw the values into the string formatting args for Sprintf. At least if you're going to use consts/variables, I'd use MakeRandomString() and friends.
80 + c.Check( osimage. LogicalSizeInGB , Equals, float32( logicalSize) ) osimage. Label, Equals, label) osimage. MediaLink, Equals, mediaLink) osimage. Name, Equals, name) osimage. EULA, Equals, eula) osimage. Description, Equals, description)
81 + c.Check(
82 + c.Check(
83 + c.Check(
84 + c.Check(osimage.OS, Equals, "Linux")
85 + c.Check(
86 + c.Check(
You can do this in a single check if you make a single "expected" struct and do a DeepEquals, as is done for some of the storage tests. The code reads better that way and you also get a single failure listing all differences at once.
103 + c.Assert( len(listing) , Equals, 3) listing[ 0].Name, Equals, "image2") listing[ 1].Name, Equals, "image1") listing[ 2].Name, Equals, "image3")
104 + c.Check(
105 + c.Check(
106 + c.Check(
Same here.
122 +// rigPreparedResp onseDispatcher sets up a request dispatcher that returns,
123 +// for each consecutive request, the next of a series of prepared responses.
This reminds me of Mocker. Out of interest, do you prefer its record/replay mocking style over the simpler Mock?
+type OSImage struct {
154 + AffinityGroup string `xml:",omitempty"`
155 + Category string
156 + Label string
[snip]
You said you were leaving out the xml tags, but please don't do that. Gavin and I talked about this in Brisbane too, but we decided that we need a strong separation between external API names and internal code struct names - if the Azure API changes then it would either mean code changes everywhere or adding the tag anyway. Adding the tags also reinforces to the code reader that its an XML-filled property.