A lot of DokuWiki's functionality is interaction driven. A way to have automated frontend tests that check that certain interactions work would be useful.

One way would be to use Selenium, which is a quite interesting testing frontend which works on the result – the website – exclusively. It would be great to use it, but there are some open questions and tasks.

Seleniumtests can be run in three different ways. Questions is what do we want?

• testrunner
  • This is a HTML/JS only application that can run the tests inside the browser
  • pretty much cross browsers compatible
  • could easily be run by end users on various systems
  • seems to be deprecated by the selenium guys
• Firefox extension
  • The best way to create tests, regardless of the final runner
  • Can load and run tests
  • Firefox only
• From a Unit Test Suite using a browser remote controller
  • the remote control server is in Java and needs to be setup and properly configured
  • theoretically cross browser tests
  • tests are written directly in the unit test framework
  • can be run automatically (for continous integration)
  • can use setup and teardown and any other PHP command between the selenium commands

There are different ways to store the test cases. We need to decide which one we want based on what we decide above.

• HTML Tables
  • this is the default format
  • this is understood by the testrunner and the Firefox extension
  • we could code some PHP to parse them in our unit test suite, but it's a bit ugly
  • manually editing them is a pain
• Some custom Format
  • writing the needed input/output filters for the Firefox extension is easy
  • User's would need to install the filters in addition to the extension
  • AFAIK the testrunner can't work with custom formats
• PHP API
  • The Firefox extension can only create PHPUnit tests by default, but we could write a filter for our tests
  • No way to use these tests outside the unit test suite

FuncUnit is a browser based frontend testing framework. The advantage would be that basically everyone can run theses tests in their specific environment which could be quite useful.

Jasmine seems to take a similar approach.

Config options like useheading would greatly change the look of the website. Tests should work with as much different sets of settings to reduce copy&pasting. Possible solutions:

• Make the DokuWiki configurable via Selenium (i. e. probably via HTTP params), so every test can load a specific configuration it is written for. Tests could not run on production instances, though.
• Make the tests as configuration-agnostic as possible. Tests would be able to accept different forms of URLs (in the urlrewrite example) and just check that the behavior is consistent with the currently used configuration.

• bug
• andi
• Adrian Lang