Linux and UNIX Man Pages

Linux & Unix Commands - Search Man Pages

test::needsdisplay(3pm) [debian man page]

Test::NeedsDisplay(3pm) 				User Contributed Perl Documentation				   Test::NeedsDisplay(3pm)

NAME
Test::NeedsDisplay - Ensure that tests needing a display have one SYNOPSIS
In your Makefile.PL... use inc::Module::Install; # ... or whatever else you use # Check for a display use Test::NeedsDisplay; # ... your Makefile.PL content as normal And again in each test script that loads Wx #!/usr/bin/perl use strict; use Test::NeedsDisplay; # Test content as normal... DESCRIPTION
When testing GUI applications, sometimes applications or modules absolutely insist on a display, even just to load a module without actually showing any objects. Regardless, this makes GUI applications pretty much impossible to build and test on headless or automated systems. And it fails to the point of not even running the Makefile.PL script because a dependency needs a display so it can be loaded to find a version. In these situations, what is needed is a fake display. The "Test::NeedsDisplay" module will search around and try to find a way to load some sort of display that can be used for the testing. Strategies for Finding a Display At this time, only a single method is used (and a very simple one). Debian Linux has a script called "xvfb-run" which is a wrapper for the "xvfb", a virtual X server which uses the linux frame buffer. When loaded without a viable display, the module will re-exec the same script using something like (for example) "xvfb-run test.t". As such, it should be loaded as early as possible, before anything has a chance to change script parameters. These params will be resent through to the script again. METHODS
There are no methods. You simply use the module as early as possible, probably right after "use strict;" and make sure to load it with only default params. Specifically, need must always load it before you set the test plan, otherwise the test script will report two plans, and the harness will complain about it and die. # Use it like this ... use Test::NeedsDisplay; # ... not like this ... use Test::NeedsDisplay 'anything'; # ... and not like this. use Test::NeedsDisplay (); And that's all there is to do. The module will take care of the rest. TO DO
- Find alternative ways to launch a display on different platforms SUPPORT
Bugs should be reported via the CPAN bug tracker at <http://rt.cpan.org/NoAuth/ReportBug.html?Queue=Test-NeedsDisplay> For other issues, contact the author. AUTHOR
Adam Kennedy <adamk@cpan.org> COPYRIGHT
Copyright 2005 - 2009 Adam Kennedy. This program is free software; you can redistribute it and/or modify it under the same terms as Perl itself. The full text of the license can be found in the LICENSE file included with this module. perl v5.10.0 2009-01-04 Test::NeedsDisplay(3pm)

Check Out this Related Man Page

Test::Object(3) 					User Contributed Perl Documentation					   Test::Object(3)

NAME
Test::Object - Thoroughly testing objects via registered handlers SYNOPSIS
################################################################### # In your test module, register test handlers again class names # ################################################################### package My::ModuleTester; use Test::More; use Test::Object; # Foo::Bar is a subclass of Foo Test::Object->register( class => 'Foo', tests => 5, code => &foo_ok, ); Test::Object->register( class => 'Foo::Bar', # No fixed number of tests code => &foobar_ok, ); sub foo_ok { my $object = shift; ok( $object->foo, '->foo returns true' ); } sub foobar_ok { my $object = shift; is( $object->foo, 'bar', '->foo returns "bar"' ); } 1; ################################################################### # In test script, test object against all registered classes # ################################################################### #!/usr/bin/perl -w use Test::More 'no_plan'; use Test::Object; use My::ModuleTester; my $object = Foo::Bar->new; isa_ok( $object, 'Foo::Bar' ); object_ok( $object ); DESCRIPTION
In situations where you have deep trees of classes, there is a common situation in which you test a module 4 or 5 subclasses down, which should follow the correct behaviour of not just the subclass, but of all the parent classes. This should be done to ensure that the implementation of a subclass has not somehow "broken" the object's behaviour in a more general sense. "Test::Object" is a testing package designed to allow you to easily test what you believe is a valid object against the expected behaviour of all of the classes in its inheritance tree in one single call. To do this, you "register" tests (in the form of CODE or function references) with "Test::Object", with each test associated with a particular class. When you call "object_ok" in your test script, "Test::Object" will check the object against all registered tests. For each class that your object responds to "$object->isa($class)" for, the appropriate testing function will be called. Doing it this way allows adapter objects and other things that respond to "isa" differently that the default to still be tested against the classes that it is advertising itself as correctly. This also means that more than one test might be "counted" for each call to "object_ok". You should account for this correctly in your expected test count. SUPPORT
Bugs should be submitted via the CPAN bug tracker, located at <http://rt.cpan.org/NoAuth/ReportBug.html?Queue=Test-Object> For other issues, contact the author. AUTHOR
Adam Kennedy <cpan@ali.as> SEE ALSO
<http://ali.as/>, Test::More, Test::Builder::Tester, Test::Class COPYRIGHT
Copyright 2005, 2006 Adam Kennedy. All rights reserved. This program is free software; you can redistribute it and/or modify it under the same terms as Perl itself. The full text of the license can be found in the LICENSE file included with this module. perl v5.16.3 2006-09-07 Test::Object(3)
Man Page

Featured Tech Videos