4:37 a.m.
Hey, folks. Today I got a PoC of testcase-stats on top of wikitcms up
and running. It's not complete yet as I haven't written the bits to
provide the CLI and page selection stuff, but all the hard stuff is
there. I'm attaching it. To test it, just stick it in the
stats/testcase-stats directory of a fedora-qa git checkout, symlink an
up-to-date checkout of the wikitcms 'results-types' branch into the same
directory, and run it. It'll output to /tmp/tcstats_test , but you can
easily change that if you like. You can also change the hard-coded list
of pages it runs on.
Tomorrow I'll aim to clean it all up and make it a relval sub-command,
then maybe release wikitcms 2.0. it may get interesting when I look at
feeding in various possible groups of pages, but I'll burn that bridge
when I come to it.
The contortions this goes through to wrangle the data into the correct
forms seem slightly inelegant, but I don't see any easy significant wins
in simplifying them - thoughts welcome. What it does is roughly this:
* Get a list of ResultRow objects for each page in the page set
* make a dict of lists of tuples (!). the keys are tuples for all the
'unique tests' for which at least one ResultRow exists, where a 'unique
test' is the combination of testcase + 'test name' - when you have
something like [[QA:Testcase_default_boot_install|Workstation live]],
QA:Testcase_default_boot_install is the testcase and "Workstation live"
is the 'test name'. the value tuples are the ResultRows for that 'unique
test'; field 0 is a string identifying the compose from which the
ResultRow comes (e.g. 'BetaTC1'), field 1 is the ResultRow object
itself. we need to keep the rows for each compose for each 'unique test'
separate.
* make another dict, using the same keys from the last one, with the
value for each key being a Test() object instantiated from the list of
tuples from the first test case. That class can now produce all the
information the HTML rendering functions need to do their stuff.
if anyone sees a way to simplify that while still making it possible for
the renderers to get all the data they need fairly simply, please do
enlighten me =) one possible thing we could do is let wikitcms provide
milestone / compose properties for resultrow objects, that might help.
I'll have to look at it tomorrow.
If I was writing this from scratch maybe I'd go about it slightly
differently, but I don't think the ugliness is sufficient to merit
burning down all josef's work and starting over. it works fine.
the actual rendering functions are more or less intact from josef's
version, I just adjusted them to consume the data from the Test()
objects. the Test() classes' __init__() is pretty much ripped from
josef's version too.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net