On Fri, Mar 12, 2010 at 3:12 PM, Conrad Irwin conrad.irwin@googlemail.com wrote:
On 03/12/2010 07:48 PM, Ryan Lane wrote:
Do the parser tests only test core parser functionality, or do they also test extensions, like ParserFunctions, and SyntaxHighlight GeSHi? It is likely we'll have tests that will need to dynamically include extensions, and configure them dynamically as well.
Yes, if you look at extensions/Poem/Poem.php, you see
$wgParserTestFiles[] = dirname( __FILE__ ) . "/poemParserTests.txt";
I'd hope this would work in exactly the same way with $wgSeleniumTestFiles. The parserTests are currently in their own light-weight file format (which isn't great, but it's certainly not terrible). I imagine that selenium tests will be (initially at least) based on the PHP exuded by the selenium IDE [see below], with code added to the setUp() for MediaWiki configuration.
For the grid setup, we were exploring the possibility of a test runner that automatically tests commits, and reports them to Code Review, like the parser tests do now. For the most part, people shouldn't be hitting the grid, only bots, unless we have a QA team that is doing something special.
Great, though obviously some cleverness is needed to avoid running all tests on all browsers on every commit, but nothing too challenging.
When selenium launches a browser, it does so using a clean profile. It launches a fresh browser from a new profile every test it runs. This shouldn't be an issue.
That's what the docs say :), I did not find this to always be the case.
Conrad
<?php require_once 'PHPUnit/Extensions/SeleniumTestCase.php'; class Example extends PHPUnit_Extensions_SeleniumTestCase { function setUp() { $this->setBrowser("*chrome"); $this->setBrowserUrl("http://en.wiktionary.org/"); } function testMyTestCase() { $this->open("/wiki/idiom"); $this->type("searchInput", "adsa"); $this->click("searchGoButton"); $this->waitForPageToLoad("30000"); } } ?>
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
This is exactly how I think it should work. Our test cases should be very lightweight, with as much work as possible deferred to a common area (abstract MediaWiki_TestCase anyone?). Each time we write a test we're reinventing the wheel and I think that should be avoided. We need a common way to setUp()--with variants for specific test-cases, of course-- a working MediaWiki instance that is consistent every time.
We want writing testcases to be as easy as humanly possible, or people won't write them. This is exactly the situation we're in right now.
-Chad