/ 
TestRail-API-0.050
River stage zero No dependents
/ App::Prove::Plugin::TestRail

NAME

App::Prove::Plugin::TestRail - Upload your TAP results to TestRail in realtime

VERSION

version 0.050

SYNOPSIS

`prove -PTestRail='apiurl=http://some.testrail.install/,user=someUser,password=somePassword,project=TestProject,run=TestRun,plan=TestPlan,configs=Config1:Config2:Config3,version=0.014' sometest.t`

DESCRIPTION

Prove plugin to upload test results to TestRail installations.

Accepts input in the standard Prove plugin fashion (-Ppluginname='key=value,key=value,key=value...'), but will also parse a config file. When fed in prove plugin style, key=value input is expected.

If \$HOME/.testrailrc exists, it will be parsed for any of these values in a newline separated key=value list. Example:

apiurl=http://some.testrail.install
user=someGuy
password=superS3cret
project=TestProject
run=TestRun
plan=GosPlan
configs=config1:config2:config3: ... :configN
version=xx.xx.xx.xx
step_results=sr_sys_name
lockname=internal_lock_name
testsuite_id=123
testsuite=blahblah #don't do this it's mutually exclusive with testuite_id
sections=section1:section2:section3: ... :sectionN
autoclose=0
encoding=UTF-8
configuration_group=Operating Systems
test_bad_status=blocked
max_tries=3

Note that passing configurations as filters for runs inside of plans are separated by colons.

If a configuration_group option is passed, it, and any configurations passed will be created automatically for you in the case they do not exist.

Values passed in via query string will override values in \$HOME/.testrailrc. If your system has no concept of user homes, it will look in the current directory for .testrailrc.

See the documentation for the constructor of Test::Rail::Parser as to why you might want to pass the aforementioned options.

CAVEATS

When running prove in multiple job mode (-j), or when breaking out test jobs into multiple prove processes, auto-spawn of plans & runs can race. Be sure to extend your harness to make sure these things are already created if you do either of these things.

Also, all parameters expecting names are vulnerable to duplicate naming issues. Try not to use the same name for:

* projects
* testsuites within the same project
* sections within the same testsuite that are peers
* test cases
* test plans and runs outside of plans which are not completed
* configurations & configuration groups

To do so will result in the first of said item found. This might result in the reuse of an existing run/plan unintentionally, or spawning runs within the wrong project/testsuite or with incorrect test sections. Similarly, duplicate named tests will result in one of the dupes never being run (as the first found is chosen).

OVERRIDDEN METHODS

load(parser)

Shoves the arguments passed to the prove plugin into $ENV so that Test::Rail::Parser can get at them. Not the most elegant solution, but I see no other clear path to get those variables downrange to it's constructor.

SEE ALSO

TestRail::API

Test::Rail::Parser

App::Prove

File::HomeDir for the finding of .testrailrc

SPECIAL THANKS

Thanks to cPanel Inc, for graciously funding the creation of this module.

AUTHOR

George S. Baugh <teodesian@cpan.org>

SOURCE

The development version is on github at https://github.com/teodesian/TestRail-Perl and may be cloned from git://github.com/teodesian/TestRail-Perl.git

COPYRIGHT AND LICENSE

This software is copyright (c) 2021 by George S. Baugh.

This is free software; you can redistribute it and/or modify it under the same terms as the Perl 5 programming language system itself.