On Tue, Aug 11, 2009 at 3:35 PM, dan nessett<dnessett(a)yahoo.com> wrote:
--- On Tue, 8/11/09, Brion Vibber
<brion(a)wikimedia.org> wrote:
These scripts should simply be updated to
initialize the
framework
properly instead of trying to half-ass it and load
individual classes.
I agree, which is why I am trying to figure out how to consolidate the tests in /tests/
and /t/. [The example I gave was to illustrate how bugs can pop up when you use code that
depends on the position of files in a distribution tree, not because I think the tests are
in good shape. The bug fixes are only intended to make these tests available again, not to
declare them finished.]
I could use some help on test system architecture - you do wear the systems architect hat
:-). It doesn't seem right to use WebStart.php to initialize the tests. For one thing,
WebStart starts up profiling, which doesn't seem relevant for a test. That leaves
Command.inc. However, the t tests stream TAP protocol text to "prove", a PERL
script that normally runs them. I have no way of running these tests through prove because
my IDE doesn't support PERL, so if I changed the tests to require Command.inc, it
would be hard to debug any problems.
I researched other TAP consumers and didn't find anything other than prove. I was
hoping that one written in PHP existed, but I haven't found anything. So, I am in kind
of a bind. We could just dump the t tests, but at least one (Parser.t, which runs
parserTests) is pretty useful. Furthermore, TAP has an IETF standardization effort and
phpunit can produce TAP output. This suggests that TAP is a good candidate for test system
infrastructure.
So, what are your thoughts on this?
Dan
_______________________________________________
Wikitech-l mailing list
Wikitech-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
To be perfectly honest, I'm of the opinion that tests/ and t/
should be scrapped and it should all be done over, properly.
What we need is an easy and straightforward way to write
test cases, so people are encouraged to write them. Right
now, nobody understands wtf is going on in tests/ and t/, so
they get ignored and the /vast/ majority of the code isn't tested.
What we need is something similar to parser tests, where it's
absurdly easy to pop new tests in with little to no coding
required at all. Also, extensions having the ability to inject
their own tests into the framework is a must IMHO.
-Chad