Programmatically validate markup of web application pages during automated acceptance testing.
Markup validator module for Codeception. Validates web-pages markup (HTML, XHTML etc.) using markup validators e.g. W3C Markup Validator Service. Don't let invalid pages reach production. Add some zero effort tests to your acceptance suite which will immediately inform you when your markup gets broken.
$I->amOnPage('/');
$I->validateMarkup();
Dead simple to use. Requires literally no configuraton. Works as you expect it out of box. Fully configurable and extendable if you want to hack it. Each component of the module can be replaced with your custom class. Just implement a simple interface and inject custom component to the module.
The recommended way of module installation is via composer:
composer require --dev kolyunya/codeception-markup-validator
Add the module to your acceptance test suit configuration:
class_name: AcceptanceTester
modules:
enabled:
- PhpBrowser:
url: 'http://localhost/'
- Kolyunya\Codeception\Module\MarkupValidator
Build the test suit:
codecept build
Validate markup:
$I->amOnPage('/');
$I->validateMarkup();
If you need, you may override module-wide message filter configuration for each page individually like this:
// Perform very strict checks for this particular page.
$I->amOnPage('/foo/');
$I->validateMarkup(array(
'ignoreWarnings' => false,
));
// Ignore those two errors just on this page.
$I->amOnPage('/bar/');
$I->validateMarkup(array(
'ignoredErrors' => array(
'/some error/',
'/another error/',
),
));
// Set error count threshold, do not ignore warnings
// but ignore some errors on this page.
$I->amOnPage('/quux/');
$I->validateMarkup(array(
'errorCountThreshold' => 10,
'ignoreWarnings' => false,
'ignoredErros' => array(
'/this error/',
'/that error/',
),
));
The module does not require any configuration. The default setup will work if you have either PhpBrowser
or WebDriver
modules enabled.
Nevertheless the module is fully-configurable and hackable. It consist of four major components: provider
which provides markup to validate, validator
which performs actual markup validation, filter
which filters messages received from the validator and printer
which determines how to print messages received from the validator. You may configure each of the components with a custom implementation.
The module may be configured with a custom provider
which will provide the markup to the validator
. The default provider
tries to obtain markup from the PhpBrowser
and WebDriver
modules.
class_name: AcceptanceTester
modules:
enabled:
- PhpBrowser:
url: 'http://localhost/'
- Kolyunya\Codeception\Module\MarkupValidator:
provider:
class: Acme\Tests\Path\To\CustomMarkupProvider
The module may be configured with a custom validator
which will validate markup received from the provider
. The default validator uses the W3C Markup Validation Service API.
class_name: AcceptanceTester
modules:
enabled:
- PhpBrowser:
url: 'http://localhost/'
- Kolyunya\Codeception\Module\MarkupValidator:
validator:
class: Acme\Tests\Path\To\CustomMarkupValidator
The module may be configured with a custom filter
which will filter messages received from the validator
. You may implement you own filter
or tweak a default one.
class_name: AcceptanceTester
modules:
enabled:
- PhpBrowser:
url: 'http://localhost/'
- Kolyunya\Codeception\Module\MarkupValidator:
filter:
class: Kolyunya\Codeception\Lib\MarkupValidator\DefaultMessageFilter
config:
errorCountThreshold: 10
ignoreWarnings: true
ignoredErrors:
- '/some error/'
- '/another error/'
The module may be configured with a custom printer
which defines how messages received from the validator
are printed. The default printer prints message type, summary, details, first line number, last line number and related markup.
class_name: AcceptanceTester
modules:
enabled:
- PhpBrowser:
url: 'http://localhost/'
- Kolyunya\Codeception\Module\MarkupValidator:
printer:
class: Acme\Tests\Path\To\CustomMessagePrinter
If you found a bug or have a feature request feel free to open an issue. If you want to send a pull request, backward-compatible changes should target the master
branch while breaking changes - the next major version branch.