Merge lp:~gz/bzr/use_testtools_timings_625594 into lp:bzr
| Status: | Merged | ||||
|---|---|---|---|---|---|
| Approved by: | Vincent Ladeuil on 2010-10-07 | ||||
| Approved revision: | 5446 | ||||
| Merged at revision: | 5467 | ||||
| Proposed branch: | lp:~gz/bzr/use_testtools_timings_625594 | ||||
| Merge into: | lp:bzr | ||||
| Diff against target: |
48 lines (+18/-2) 2 files modified
bzrlib/tests/__init__.py (+3/-2) bzrlib/tests/test_selftest.py (+15/-0) |
||||
| To merge this branch: | bzr merge lp:~gz/bzr/use_testtools_timings_625594 | ||||
| Related bugs: |
|
| Reviewer | Review Type | Date Requested | Status |
|---|---|---|---|
| Vincent Ladeuil | 2010-09-27 | Approve on 2010-09-29 | |
|
Review via email:
|
|||
Commit Message
Use testtools timing mechanisms.
Description of the Change
The bzr half of the fix for bug 625594, see <lp:~gz/testtools/result_timings_forwarding_625594> for the testtools part.
Simply switches the test timing mechanism to use the api testtools provides, which enables the adaptation of subunit timestamp streams to work for bzr selftest as well without further changes.
There are some downsides here, we switch from tracking nice simple unix timestamps to datetime instances, which are harder to work with and also prevents switching to time.clock on windows for higher than 60Hz tick rate.
| Martin Packman (gz) wrote : | # |
| Vincent Ladeuil (vila) wrote : | # |
Sounds good to me.
I'm curious to see if it pqm will accept it giving the relationship with testtools but if it lands, let's do that. (We are still waiting for testtools-0.9.6 to be deployed there anyway).
| Vincent Ladeuil (vila) wrote : | # |
waitaminute
babune is currently using your testtools change and now display times for tests...
So is *this* patch really needed after all ?
| Martin Packman (gz) wrote : | # |
> So is *this* patch really needed after all ?
It's needed for normal use with `bzr selftest -v` on the terminal, I'd forgotten that babune says subunit all the way through to the output formatting so (apart from the test added here failing) isn't affected by this change.
I'm pretty confident this will pass PQM, the blame on the testtools code this is depending on is from the end of 2009 so predates 0.9.2 which is our current min version.
| Martin Packman (gz) wrote : | # |
...that was unclear, I'll try again. The code change here has no effect on babune beyond making the test added pass, whereas it would fail without it.
| Vincent Ladeuil (vila) wrote : | # |
sent to pqm by email

There's a run that vila launched on babune with this change and the testtools change with a subset of the tests: babune. ladeuil. net:24842/ view/debug/ job/selftest- subset- all/93/ aggregatedTestR eport/>
<http://
Has some interesting things you can drill down to from the grouped timings, for instance, of the 10 seconds it takes to run bt.test_ workingtree_ 4 on gentoo: babune. ladeuil. net:24842/ job/selftest- subset- gentoo/ 75/testReport/ bzrlib. tests.test_ workingtree_ 4/TestWorkingTr eeFormat4/> updates_ hash_cache and test_observed_ sha1_cachable (they sleep).
<http://
There are 4 seconds each in test_commit_
Also useful for comparing the different platforms on the same suite or test.