Merge lp:~jtv/gwacl/block-on-accepted into lp:gwacl
Status: | Merged |
---|---|
Approved by: | Jeroen T. Vermeulen |
Approved revision: | 88 |
Merged at revision: | 87 |
Proposed branch: | lp:~jtv/gwacl/block-on-accepted |
Merge into: | lp:gwacl |
Diff against target: |
97 lines (+28/-9) 2 files modified
managementapi.go (+20/-8) x509session.go (+8/-1) |
To merge this branch: | bzr merge lp:~jtv/gwacl/block-on-accepted |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Raphaël Badin (community) | Approve | ||
Review via email: mp+156502@code.launchpad.net |
Commit message
Block on additional API operations that *might* require polling.
Description of the change
You'll notice that I did not test for this. Believe me, it took a lot of soul-searching. Am I not just making up excuses?
But the cost-benefit ratio is far out of whack. It's just a trivial function call (so in Go, 4 lines of code with a cyclomatic complexity of 2, sigh) and it happens in many many places. Most of this branch would be brain-dead repetitive testing. And the main risk that a test suite should guard us against is for is forgetting to make the call in the first place. If we can forget to add the call in one function, chances are we'll forget the test for that function as well!
Instead, I documented the need to call blockUntilCompl
Jeroen
Looks good, but I confess I'm not entirely happy with the lack of tests. Looks like waiting for the operation to complete is a pretty important piece of what this lib does now.
> And the main risk that a test suite should guard us against is for is forgetting to make the call in the first place.
> If we can forget to add the call in one function, chances are we'll forget the test for that function as well!
The tests for the management methods are pretty repetitive and we often copy and paste an existing test when creating a new test for a new method. For this reason, I don't think we are at risk of forgetting to test that the call to blockUntilCompl eted() is there because it will already be in the copied test.
Also, you talk about adding new methods but the tests also guard us against non-intended changes to the existing code.
How about something along the lines of: http:// paste.ubuntu. com/5670027/