NAME

http-cuke - Cucumber-style HTTP configuration testing for the masses

SYNOPSIS

Example of test scenario:

Feature: Front page responds correctly
In order to avoid problems with caching logic and/or frontend configuration
As an operations ninja
I want to check that front page is served correctly and the frontends configuration is correct

Scenario: HTTP to HTTPS redirects are in place
  When I go to "http://my.example.server.lan/"
  Then I should be redirected to "https://my.example.server.lan/"
  Then the final HTTP status code should be "200"

Put that text in a whatever.test file, and point http-cuke to the directory that contains it with:

http-cuke --test-dir ./some-tests

Or run just a single test file:

http-cuke --test ./single.test

Have a look at the tests directory where you will find this example:

Feature: Google front page allows me to search
In order not to be stuck without being able to google something
As a curious person
I want to be check that Google is available

Scenario: Google frontpage is available
  Given the HTTP request header "Accept-Language" is "en"
  When I go to "http://www.google.com/"
  Then the final HTTP status code should be "200"
  Then the page should contain "Google"

This is a test you can actually run with:

cd bin
./http-cuke --test ../tests/example.test

You can also use variables in your test files. See the "VARIABLES SUPPORT" chapter.

DESCRIPTION

Run cucumber style tests against any HTTP server.

If you are not familiar with cucumber, check it out at http://cukes.info/.

With this tool you can define set of tests (or features and scenarios in cucumber-speak) and run them.

The type of tests that http-cuke can help you with are those that involve checking a HTTP server configuration, behavior or plain responses.

You can check redirects, response headers, cookies, response bodies, inject custom HTTP headers in the requests, check Varnish responses, and more.

OTHER SUPPORTED OPTIONS

--allow-insecure-ssl

When this option is specified, http-cuke will silently connect to HTTPS hosts without verifying SSL certificates validity!. This is INSECURE, so only do it if you are aware of the implications.

The typical use case is to connect to individual backends part of a bigger cluster typically behind a load balancer.

--useragent-timeout

How long should the user agent that makes the requests wait for backend requests. This is using LWP::UserAgent, so don't expect perfect control of client timeout. For example, this will usually not include eventual DNS timeouts/slowdowns, so the actual timeout might be much longer than you specify.

Usage:

http-cuke --useragent-timeout 10 --test ...

--useragent-string

Override the default user agent string (http-cuke/version).

Usage:

http-cuke --useragent-string 'MyWebSiteTesterFTW/0.01'

MOTIVATION: THE WHY

This tool is not meant to replace tools like WWW::Mechanize or similar ones. It is meant to perform automated testing for frontends configuration testing.

By frontend I mean Apache, Nginx, Varnish, and deadly combinations of the three. It can be a nightmare to make sure you have all the correct redirects in place, that pages are cached according to your own logic, etc...

Yes, but even then, after all, cucumber is pretty well established. So why?

Because of the dependencies mess. I don't want to depend on too many packages, and Perl already has all the tools I needed to do this. I just glued them together, and there you have a TAP-compliant cucumber-style HTTP testing that can easily be hooked up to Jenkins, GitLab or your preferred CI/CD system.

The main advantage of this tool is that it opens up even complex HTTP testing to a broader audience, not necessarily programmers. That is, btw, a major point of BDD testing, and that's Good(tm).

VARIABLES SUPPORT

Here's an example of test script in Cucumber style:

Feature: My service can be monitored correctly by Nagios
In order to make sure that Nagios alerts don't fire unnecessarily
As an operations ninja
I want to verify that the resources accessed by Nagios are always available

Scenario: ping.html page is served over http
  When I go to "http://my.server.local/ping.html"
  Then the final HTTP status code should be "200"
  Then the page should contain "I am alive"

It is possible (and desirable) to embed variables in your test files. In the example above, instead of hardcoding the http://my.server.local address, you can use a variable like this:

Scenario: ping.html page is served over http
  When I go to "{{ SERVER_URL }}/ping.html"
  Then the final HTTP status code should be "200"
  Then the page should contain "I am alive"

To run this test, you need to invoke http-cuke with the -D option, to define variables. Example:

http-cuke --test ./nagios.test -D SERVER_URL=http://my.server.local

If you use variables in your test scripts, but omit to declare them when invoking http-cuke, you will be warned with a message:

Undefined variable 'SERVER_URL' in line:

  When I go to "{{ SERVER_URL }}/ping.html"

AVAILABLE TESTS

So what are the magic words that are available to build the test cases?

Here's a list:

Given a max of (\d+) redirects

Given a timeout of (\d+) seconds

Given a "(.+)" user agent

Given the HTTP request header "(.+)" is "(.*)"

Given the client sends a cookie "(.+)" with value "(.*)"

When I go to "(.+)"

When I send a ([A-Z]+) request to "([^"]+)"

When I send a ([A-Z]+) request to "([^"]+)" with body "(.*)"

A super-cheap hack, but it works for now. Examples:

When I send a GET request to "http://somedomain.lan/"
When I send a POST request to "http://somedomain.lan/" with body ""
When I send a PATCH request to "http://somedomain.lan/some-api" with body "{"hello":"there"}"

Then the page should be cached

Then the page should not be cached

Then I should be redirected to "(.+)"

Then I should not be redirected to "(.+)"

Then the HTTP response header "(.+)" should match "(.*)"

Then the HTTP status code should be "(.+)"

Then the HTTP status code should not be "(.+)"

Then the HTTP response header "(.+)" should not be there

Then the HTTP response header "(.+)" should be "(.+)"

Then the HTTP response header "(.+)" should match "(.+)"

Then the HTTP status line should match "(.+)"

Then the page should contain "(.+)"

Then the page should not contain "(.+)"

Then the server should send a CSRF token

Then the page MD5 checksum should be "(.+)"

Then the page should be a valid JSON document

Then the page should validate according to the external script "(.+)"

In this case, the specified external script, which must be executable, will be invoked with the content of the downloaded document as STDIN stream.

The script must exit with code zero (e.g. exit 0) if the document is valid. Any other exit code will be interpreted as if the document failed validation.

Then the json document should have a "(.+)" key

Then the json value for the "(.+)" key should not be empty

Then the json value for the "(.+)" key should be "(.+)"

Then the json value for the "(.+)" key should be (greater|lesser) than "(.+)"

Then the json value for the "(.+)" key should be a timestamp within (\d+) (hours?|minutes?|seconds?|days?)

AUTHOR

Cosimo Streppone, cosimo@cpan.org

LICENSE AND COPYRIGHT

This code is offered under the Open Source BSD license.

Copyright (c) 2012-2017, Opera Software. All rights reserved.
Copyright (c) 2018, Kahoot! AS. All rights reserved.

Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:

• Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.

• Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.

• Neither the name of Opera Software, Kahoot! AS nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission.

DISCLAIMER OF WARRANTY

THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.