The change I made was to add a "flipresult" option that simply turns a success into a failure and a failure into a success. This is what I understood I was asked to do. On the plus side, this approach also allows the addition of parser tests that are supposed to fail (not just have always failed). On the negative side it does hide problems that perhaps should remain in the open.
I just looked at the code and it shouldn't be hard to add a knowntofail option that acts like flipresult and then add a new category of test result that specifies how many known to fail results occurred. However, one issue is whether known to fail should count against success/failure (when computing the percentage of tests that failed) or whether these results should not count toward either.
Would someone tell me where the redirect from index.php to index.php/Main_Page occurs in the page processing flow?
--- On Tue, 7/21/09, Kwan Ting Chan ktc@ktchan.info wrote:
From: Kwan Ting Chan ktc@ktchan.info Subject: Re: [Wikitech-l] "known to fail" switch added to parserTests To: "Wikimedia developers" wikitech-l@lists.wikimedia.org Date: Tuesday, July 21, 2009, 4:43 AM Aryeh Gregor wrote:
On Tue, Jul 21, 2009 at 9:56 AM, Gerard Meijssengerard.meijssen@gmail.com
wrote:
There is no point having a perfect score when it
is actually a lie. It seems
to me that Brion is against the removal of these
tests because he wants them
to pass. Having a third state of "known to fail"
makes sense, just changing
them to pass makes it necessary to add a "citation
needed" because it is
just not true.
Nobody's changing them to pass.
I can understand where Gerard got the impression:
"I have modified parserTests to take a "known to fail" switch so those tests that have always failed now pass." - dan nessett 2009-07-20 16:09
KTC
-- Experience is a good school but the fees are high. - Heinrich Heine
-----Inline Attachment Follows-----
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l