Merge lp:~gz/juju-release-tools/test_apply_patches into lp:juju-release-tools
Proposed by
Martin Packman
Status: | Merged |
---|---|
Approved by: | Martin Packman |
Approved revision: | 324 |
Merged at revision: | 322 |
Proposed branch: | lp:~gz/juju-release-tools/test_apply_patches |
Merge into: | lp:juju-release-tools |
Prerequisite: | lp:~gz/juju-release-tools/utils_no_mock |
Diff against target: |
203 lines (+171/-5) 2 files modified
apply_patches.py (+11/-5) tests/test_apply_patches.py (+160/-0) |
To merge this branch: | bzr merge lp:~gz/juju-release-tools/test_apply_patches |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Curtis Hovey (community) | code | Approve | |
Review via email: mp+300776@code.launchpad.net |
This proposal supersedes a proposal from 2016-07-21.
Commit message
Add test coverage for apply_patches script
Description of the change
Somehow I forgot on Friday that we do actually have test infrastructure for juju-release-tools, so this branch adds coverage. There are some fiddly bits (`with open` is always annoying), and one relevent change with the addition of flushing for the parent process's output. This ensures the ordering of output is correct when mixed with the patch command, which currently is a confusion on the logs.
The addition of gettext for the user informational output is total vanity. Please forgive.
To post a comment you must log in.
Do we need print_now? I have strived to move away from it. I introduced it because the buffered stdout was not appearing near the output of other procs. Per you own example, I log.XXX() which is unbuffered stderr. I print() to stdout for user info. Do we have a buffering problem that this solves?
Removing it might be awkward because I can see a few tests are mocking it.