Previous
entry.
The numbers I posted earlier about zope.testing self-test coverage were
incorrect. It turns out that when a test runner tries to trace a test that
tests that a (different) test runner can use tracing to trace (different)
tests, they both compete over a single sys.settrace() hook and only one of them
wins. Basically you get to choose between a failing test or incomplete test
coverage that ignores all subsequent tests.
If I skip the three tests that invoke sys.settrace() and run the rest with
--coverage, I get that the zope.testing test suite covers 73% of the code.
That's not bad, considering that some of the code is only invoked in a
subprocess (which we cannot trace), and some of the code is platform-specific
(if sys.platform == 'win32'), and some is Python-version-specific.
If I monkey-patch sys.settrace to set the hook only the first time it's called,
I get one failing test (as expected) and I see 77% test coverage.
Oh, I forgot: that's the coverage with my prototype colorizing code which
doesn't have unit tests yet. On trunk the coverage reaches 81%.
By the way, yesterday was the first time I saw an OLPC laptop in real life. It's so small and
cute.
Vika holding the XO laptop. What does XO mean, anyway?
Technorati tag: europython2007
Previous
entry.
During the second day I refactored the Zope 3 test runner to make nearly all
of its output go through a single OutputFormatter class (in the output-refactoring
branch), then created a subclass of it that uses ANSI color codes to
highlight error messages (in the colorized-output
branch). I've had this luxury before, and I can attest that it does
increase productivity (being able to spot filenames and line numbers between
several-hundred-line diffs produced by testbrowser tests is invaluable).
I also had lots of fun trying to get the unit test coverage of the test
runner. There's a bit of a chicken and egg problem here: to get accurate
coverage data you want the tracer to be enabled during import time, but you
cannot do that since the test runner doesn't exist yet. Hacks with
reload() and del sys.modules['zope.testing.testrunner']
didn't work due to excessive monkey-patching in the test runner that caused
infinite recursion. In the end I made a second copy of the module and used it to
run the test suite of the first copy. (42% of the code is not covered by unit
tests, according to the coverage report. I don't entirely trust that report,
though.)
On the last day I intend to clean up the code, add the unit tests for my
colorizer, and merge it to trunk.
Continued...
Technorati tag: europython2007
Previous entry.
During the first day of the sprints I fixed a couple of small zope.testing
test failures on Python 2.5, but didn't get anything significantly useful done.
It was more of a leisurely walk than a sprint. At least I did get acquainted
with the changed environment (buildout's bootstrap script that
does exec urllib.urlopen('http://...').read() and requires the very
latest bleeding edge setuptools
that aren't in Ubuntu Feisty yet) and found a machine that still had Python 2.3
to run tests on.
I was also a bit disappointed that my two-line
bugfix to trace.py that I submitted more than a year ago wasn't
accepted yet and the tests were spewing spurious messages about not printing
coverage results for module '<doctest ...>'.
Continued...
Technorati tag: europython2007
The EuroPython conference was in my
home town, Vilnius, this year. The conference is over now, but the sprints will continue until
Saturday.
If I had to pick the three most interesting (to me) talks, I'd choose
Sadly, none of them have the slides available for download yet.
The lightning talks were also very interesting and entertaining (have you
seen the Grok trailer?).
Continued...
Technorati tag: europython2007
