| Name : perl-Test-Clustericious-Cluster
| |
| Version : 0.35
| Vendor : obs://build_opensuse_org/devel:languages:perl
|
| Release : 1.1
| Date : 2017-06-10 11:51:14
|
| Group : Development/Libraries/Perl
| Source RPM : perl-Test-Clustericious-Cluster-0.35-1.1.src.rpm
|
| Size : 0.08 MB
| |
| Packager : (none)
| |
| Summary : Test an imaginary beowulf cluster of Clustericious services
|
Description :
This module allows you to test an entire cluster of Clustericious services
(or just one or two). The only prerequisites are Mojolicious and
File::HomeDir, so you can mix and match Mojolicious, Mojolicious::Lite and
full Clustericious apps and test how they interact.
If you are testing against Clustericious applications, it is important to
either use this module as early as possible, or use File::HomeDir::Test as
the very first module in your test, as testing Clustericious configurations
depend on the testing home directory being setup by File::HomeDir::Test.
In addition to passing Clustericious configurations into the
\'create_cluster_ok\' method as describe below, you can include configuration
in the data section of your test script. The configuration files use
Clustericious::Config, so you can use Mojo::Template directives to embed
Perl code in the configuration. You can access the
Test::Clustericious::Cluster instance from within the configuration using
the \'cluster\' function, which can be useful for getting the URL for the
your and other service URLs.
__DATA__
AATTAATT etc/Foo.conf
---
url < %= cluster->url %>
% # because YAML is (mostly) a super set of JSON you can
% # convert perl structures into config items using json
% # function:
% # (json method requires Clustericious::Config 0.25)
other_urls: < %= json [ AATT{ cluster->urls } ] %>
You can also put perl code in the data section of your test file, which can
be useful if there isn\'t a another good place to put it. This example
embeds as Mojolicious app \"FooApp\" and a Clustericious::App \"BarApp\" into
the test script itself:
...
$cluster->create_cluster_ok(\'FooApp\', \'BarApp\');
...
__DATA__
AATTAATT lib/FooApp.pm
package FooApp;
use Mojo::Base qw( Mojolicious );
sub startup
{
shift->routes->get(\'/\' => sub { shift->render(text => \'hello there from foo\') });
}
1;
AATTAATT lib/BarApp.pm
package BarApp;
use strict;
use warnings;
use base qw( Clustericious::App );
1;
AATTAATT lib/BarApp/Routes.pm
package BarApp::Routes;
use strict;
use warnings;
use Clustericious::RouteBuilder;
get \'/\' => sub { shift->render(text => \'hello there from bar\') };
1;
These examples are full apps, but you could also use this feature to
implement mocks to test parts of your program that use resources that
aren\'t easily available during unit testing, or may change from host to
host. Here is an example that mocks parts of Net::hostent:
use strict;
use warnings;
use Test::Clustericious::Cluster;
use Test2::Bundle::More;
plan 2;
eval q{ use Net::hostent };
is $AATT, \'\';
is gethost(\'bar\')->name, \'foo.example.com\', \'gethost(bar).name = foo.example.com\';
__DATA__
AATTAATT lib/Net/hostent.pm
package Net::hostent;
use strict;
use warnings;
use base qw( Exporter );
our AATTEXPORT = qw( gethost );
sub gethost
{
my $input_name = shift;
return unless $input_name =~ /^(foo|bar|baz|foo.example.com)$/;
bless {}, \'Net::hostent\';
}
sub name { \'foo.example.com\' }
sub aliases { qw( foo.example.com foo bar baz ) }
1;
|
RPM found in directory: /packages/linux-pbone/ftp5.gwdg.de/pub/opensuse/repositories/devel:/languages:/perl:/CPAN-T/openSUSE_Tumbleweed/noarch |
