aklump / check-pages
Very simple QA for websites.
Requires
- php: ^7.4
- ext-curl: *
- ext-dom: *
- ext-json: *
- aklump/local-timezone: ^0.0.1
- aklump/loft-lib: ^2
- behat/mink: ^1.8
- chrome-php/chrome: ^1.8
- dmore/chrome-mink-driver: ^2.7
- guzzlehttp/guzzle: ^6.3|^7.0
- justinrainbow/json-schema: ^5.2
- laminas/laminas-xml2json: ^3.2
- ralouphie/mimey: ^2.1
- ramsey/collection: ^1.3
- shanethehat/pretty-xml: ^1.0
- spatie/browsershot: ^3.57
- symfony/config: ^4.4|^5.4
- symfony/console: ^4.4|^5.4
- symfony/css-selector: ^3.4|^4.0|^5.0
- symfony/dependency-injection: ^4.4|^5.4
- symfony/dom-crawler: ^5.0
- symfony/event-dispatcher: ^4.4|^5.4
- symfony/expression-language: ^4.4|^5.4
- symfony/yaml: ^3.4|^4.0|^5.0
- wikimedia/composer-merge-plugin: ^2.1
Requires (Dev)
- drupal/coder: ^8.3
- phpunit/phpunit: ^9.5
- squizlabs/php_codesniffer: ^3.5
- dev-master
- 0.23.0
- 0.22.0
- 0.21.0
- 0.20.1
- 0.20.0
- 0.19.1
- 0.19.0
- 0.18.0
- 0.17.0
- 0.16.8
- 0.16.7
- 0.16.6
- 0.16.5
- 0.16.4
- 0.16.3
- 0.16.2
- 0.16.1
- 0.16.0
- 0.15.2
- 0.15.1
- 0.15.0
- 0.14.0
- 0.13.1
- 0.13.0
- 0.12.0
- 0.11.1
- 0.11.0
- 0.10.2
- 0.10.1
- 0.10.0
- 0.9.0
- 0.7.2
- 0.7.1
- 0.7.0
- 0.5.2
- 0.5.1
- 0.5.0
- 0.4.0
- 0.2.13
- 0.2.12
- 0.2.11
- 0.2.10
- 0.2.9
- 0.2.8
- 0.2.7
- 0.2.6
- 0.2.5
- 0.2.4
- 0.2.3
- 0.2.2
- 0.2.1
- 0.2.0
- 0.1.3
- 0.1.2
This package is auto-updated.
Last update: 2024-11-19 00:29:46 UTC
README
Check Pages
Very Simple QA for HTTP
Heavy Development
Use at your own risk. This project is under heavy development and is undergoing changes pretty regularly.
Summary
This project intends to provide a process of QA testing of a website, which is very fast to implement and simple to maintain. You write your tests using YAML and they can be as simple as checking for a 200 HTTP response on the homepage.
- visit: /
Or ensuring the admin section is protected.
-
visit: /admin
why: Make sure the `/admin` path returns 403 forbidden when not logged in.
status: 403
In a third test we can assert there is one logo image on the homepage, like so:
- visit: /
find:
- dom: '#logo img'
count: 1
Lastly, make sure there are no unprocessed tokens on the page (a.k.a. a substring does not appear):
- visit: /
find:
- not contains: '[site:name]'
For more code examples explore the /examples directory.
Visit https://aklump.github.io/check_pages for full documentation.
Clarity of Purpose and Limitation
The mission of this tool is to provide testing for URLS and webpages in the most simple and concise syntax possible. For testing scenarios that require element interaction, such as clicks, hovers, scrolling, etc, there are amazing projects out there such as Cypress. This project will never try to compete with that crowd, and shall always restrict it's testing of the DOM to assertions against a single snapshot of the loaded URL.
Terms Used
- Test Runner - A very simple PHP file that defines the configuration and what test suites to run, and in what order. @see includes/runner.php.
- Test Suite - A YAML file that includes one or more checks against URLs. @see includes/suite.yml.
- Test - A single URL check within a suite.
- Assertion - A single check action against the HTTP response of a test, i.e., headers, body, status code, javascript, etc.
Requirements
- You must install with Composer.
- Tests suites are written in YAML.
- Little to no experience with PHP is necessary. Copy and paste will suffice.
Install
$ composer require aklump/check-pages --dev
- In most cases the
--dev
is appropriate, but use your own discretion. - You will be asked if you want to create a directory for your tests when you install. This will copy over a basic scaffolding to build from.1
- More detailed examples are located in the example directory.
Example Tests Demo
If you are new to this project and would like to see a demonstration, it would be a good idea to start with the examples. Run the example tests with the following commands. Then open up the files in the example/tests directory and study them to see how they work.1
-
Open a new shell window which will run the PHP server for our example test pages.
$ ./bin/start_test_server.sh
-
Open a second shell window to execute the tests.
$ ./bin/run_tests.sh
1 If you see no tests directory then create one and copy the contents of examples into tests. The example tests directory will only be created if you use create-project
as the installation method.
Writing Your First Test Suite
checkpages init
to create tests directory and runner in the current directory.
Multiple Configuration Files
The project is designed to be able to run the same tests using different configurations. You can create multiple configuration files so that you are able to run the same test on live and then on dev, which have different base URLs.
.
└── tests
├── config/dev.yml
├── config/live.yml
├── suite.yml
└── runner.php
In runner.php use the following line to specify the default config file:
load_config('config/dev');
When you're ready to run this using the live config add the config filename to the CLI command, e.g.,
$ ./check_pages runner.php --config=config/live
Test functions
The test functions for your PHP test files are found in includes/runner_functions.inc.
Is JS Supported?
Yes, not by default, but you are able to indicate that given tests requires Javascript be run. Read on...
Javascript Testing Requirements
- Your testing machine must have Chrome installed.
Enable Javascript per Test
Unless you enable it, or in the case the selector type (i.e., style
, javascript
) requires it, javascript is not run during testing. If you need
to assert that an element exists, which was created from Javascript (or
otherwise need javascript to run on the page), you will need to indicate the
following in your test, namely js: true
.
- visit: /foo js: true find: - dom: .js-created-page-title text: Javascript added me to the DOM!
Asserting Javascript Evaluations
Let's say you want to assert the value of the URL fragment. You can do that with
the javascript
selector. The value of javascript
should be the expression to
evaluate, once the page loads. Notice that you may omit the js: true
as it
will be set automatically.
- visit: /foo find: - javascript: location.hash is: "#top"
Javascript Testing Related Links
- Chrome DevTools Protocol 1.3
- Learn more
- CLI parameters
- More on parameters
- https://github.com/GoogleChrome/chrome-launcher
- https://peter.sh/experiments/chromium-command-line-switches/
- https://raw.githubusercontent.com/GoogleChrome/chrome-launcher/v0.8.0/scripts/download-chrome.sh
Filter
Use --filter
to limit which suites are run.
The value passed to the filter will be matched against the $group/$id
of the suite. Behind the scenes it is treated as a regex pattern, if you do not include delimiters, they will be added and case will not matter.
Given the following test suites...
.
├── api
│ ├── menus.yml
│ ├── reports.yml
│ └── users.yml
└── ui
├── footer.yml
├── login.yml
└── menus.yml
Notice the usage of the /
separator to control how the group influences the result.
Complex Filter
It's possible to provide a complex filter that uses or
logic like this:
./check_pages runner.php -f reports -f menus
Troubleshooting
Try using the --response
to see the response source code as well.
./check_pages runner.php --response
Usage
In this case, since the project will be buried in your vendor directory, you will need to provide the directory path to your test files, when you run the test script, like this:
./vendor/bin/check_pages runner.php --dir=./tests_check_pages
This example assumes a file structure like this:
.
├── tests_check_pages
│ └── runner.php
└── vendor
└── bin
└── check_pages
Contributing
If you find this project useful... please consider making a donation.