On Tue, Jul 21, 2009 at 10:45 AM, dan nessett<[email protected]> wrote: > 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.
This isn't a good idea, no. The important thing is if someone runs parserTests.php, they should be able to easily tell whether there are any regressions in their working copy. But if we're going to keep the known-to-fail tests at all, it doesn't make a lot of sense to report them as passing when they're actually failing . . . if we do that we may as well just drop them. > 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. It should be made clear that some tests are failing, but that they are not regressions. > Would someone tell me where the redirect from index.php to > index.php/Main_Page occurs in the page processing flow? I don't know offhand. _______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
