NAME Test::FITesque::RDF - Formulate Test::FITesque fixture tables in RDF SYNOPSIS my $suite = Test::FITesque::RDF->new(source => $file)->suite; $suite->run_tests; See `t/integration-basic.t` for a full test script example. DESCRIPTION This module enables the use of Resource Description Framework to describe fixture tables. It will take the filename of an RDF file and return a Test::FITesque::Suite object that can be used to run tests. The RDF serves to identify the implementation of certain fixtures, and can also supply parameters that can be used by the tests, e.g. input parameters or expectations. See Test::FITesque for more on how the fixtures are implemented. ATTRIBUTES AND METHODS This module implements the following attributes and methods: `source` Required attribute to the constructor. Takes a Path::Tiny object pointing to the RDF file containing the fixture tables. The value will be converted into an appropriate object, so a string can also be supplied. `suite` Will return a Test::FITesque::Suite object, based on the RDF data supplied to the constructor. `transform_rdf` Will return an arrayref containing tests in the structure used by Test::FITesque::Test. Most users will rather call the `suite` method than to call this method directly. `base_uri` A IRI to use in parsing the RDF fixture tables to resolve any relative URIs. RDF EXAMPLE The below example starts with prefix declarations. Since this is a pre-release, some of the prefixes are preliminary examples. Then, the tests in the fixture table are listed explicitly. Only tests mentioned using the `test:fixtures` predicate will be used. Tests may be an RDF List, in which case, the tests will run in the specified sequence, if not, no sequence may be assumed. Then, two test fixtures are declared. The `test:handler` predicate is used to identify the class containing implementations, while `dc:identifier` is used to name the function within that class. The `test:params` predicate is used to link the parameters that will be sent as a hashref into the function. The key of the hashref will be the local part of the predicate used in the description (i.e. the part after the colon in e.g. `my:all`). It is up to the test writer to mint the URIs of the parameters, and the `param_base` is used to set indicate the namespace, so that the local part can be resolved, if wanted. The resolution itself happens in URI::NamespaceMap. @prefix test: . @prefix deps: . @prefix dc: . @prefix my: . <#test-list> a test:FixtureTable ; test:fixtures <#test1>, <#test2> . <#test1> a test:Test ; test:handler "Internal::Fixture::Simple"^^deps:CpanId ; dc:identifier "string_found" ; test:param_base ; test:params [ my:all "counter-clockwise dahut" ] . <#test2> a test:Test ; test:handler "Internal::Fixture::Multi"^^deps:CpanId ; dc:identifier "multiplication" ; test:param_base ; test:params [ my:factor1 6 ; my:factor2 7 ; my:product 42 ] . BUGS Please report any bugs to . SEE ALSO AUTHOR Kjetil Kjernsmo . COPYRIGHT AND LICENCE This software is Copyright (c) 2019 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.