NAME

Web::Solid::Test::HTTPLists - Solid Tests using HTTP objects

SYNOPSIS

  use Test::FITesque::RDF;
  my $suite = Test::FITesque::RDF->new(source => $file, base_uri => $ENV{SOLID_REMOTE_BASE})->suite;
  $suite->run_tests;
  done_testing;

A script tests/httplists.t can be used to launch some of these tests.

DESCRIPTION

Introduction

The basic idea with these tests is to simplify reuse and formulation of fixture tables using the Resource Description Framework (RDF), in this case using HTTP vocabularies to formulate lists of requests and responses. It is in an early stage, but there are running tests in this module. See Web::Solid::Test for more on the philosophy.

This system is built on Test::FITesque::RDF, which adds RDF fixture tables to Test::FITesque.

IMPLEMENTED TESTS

Apart from some author tests in this module, examples of actual tests can be found in the Solid Test Suite.

Test scripts

In general, tests are formulated in RDF fixture tables, which parameterizes the test cases. This parameterization is then given to the test scripts. It is intended therefore that only a small number of fairly general test scripts will be needed to provide an extensive test suite.

These are the test scripts implemented in this module:

http_req_res_list

Runs a list of HTTP request response pairs, checking response against the response.

Parameters

• test:steps

  A list of request-response pairs, declared using:

  • test:request

    An RDF list of requests that will be executed towards the server in SOLID_REMOTE_BASE.

  • test:response_assertion

    An RDF list of responses that will be used as corresponding expected responses in the tests.

• http://example.org/httplist/param#bearer

  A bearer token that if present will be used to authenticate the requests given by the above list. The object of this predicate can either be a literal bearer token, or a URL, in which case, it will be dereferenced and the content will be used as the bearer token.

Environment

None

Implements

1. That responses are HTTP::Response objects.

2. That the response code matches the expected one if given. A regular expression may be used.

3. That all headers given in the asserted response matches a header in the actual response.

http_req_res_list_regex_reuser

Runs a list of two HTTP request response pairs, using a regular expression from the first request to set the request URL of the second.

Parameters

Uses test:steps like above.

Additionally, the first request may have a regular expression that can be used to parse data for the next request(s). To examine the Link header, a response message can be formulated like (note, it practice it would be more complex):

 :check_acl_location_res a http:ResponseMessage ;
    httph:link '<(.*?)>;\\s+rel="acl"'^^dqm:regex ;
    http:status 200 .

The resulting match is placed in an array that will be used to set the Request URI of the next request(s).

Environment

None

Implements

1. That the regular expression in the first request matches.

2. That responses are HTTP::Response objects.

3. That the response code matches the expected one if given.

4. That headers that are not matched as regular expression but given in the asserted response matches a header in the actual response.

Assumptions

See the source for details.

NOTE

The parameters above are in the RDF formulated as actual full URIs, but where the local part is used here and resolved by the Test::FITesque::RDF framework, see its documentation for details.

To run tests against a server that uses HTTPS but uses a self-signed certificate, the certificate's fingerprint needs to be supplied to the test script to use in the validation. To set this, use the environment variable SOLID_SSL_FINGERPRINT. The fingerprint can be obtained for example by visiting the system under test in a browser and examine the certificate details from there.

There are two SSL implementations in wide use, Net::SSL and IO::Socket::SSL. The latter has largely supplantet the former, and the the former has been known to cause the test suite to "hang" for two minutes. Nevertheless, certain setups may still have it as the default. To ensure that IO::Socket::SSL is used, the environment variable PERL_NET_HTTPS_SSL_SOCKET_CLASS can be set to IO::Socket::SSL

TODO

The namespaces used in the current fixture tables are examples, and will be changed before an 1.0 release of the system.

BUGS

Please report any bugs to https://github.com/kjetilk/p5-web-solid-test-basic/issues.

AUTHOR

Kjetil Kjernsmo <kjetilk@cpan.org>.

COPYRIGHT AND LICENCE

This software is Copyright (c) 2019, 2020 by Inrupt Inc.

This is free software, licensed under:

  The MIT (X11) License

DISCLAIMER OF WARRANTIES

THIS PACKAGE IS PROVIDED "AS IS" AND WITHOUT ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE.

cpanm Web::Solid::Test

perl -MCPAN -e shell
install Web::Solid::Test