1Test::Base(3) User Contributed Perl Documentation Test::Base(3)
2
6 Test::Base - A Data Driven Testing Framework
7
9 A new test module:
10 # lib/MyProject/Test.pm
12 package MyProject::Test;
13 use Test::Base -Base;
14 use MyProject;
16 package MyProject::Test::Filter;
18 use Test::Base::Filter -base;
19 sub my_filter {
21 return MyProject->do_something(shift);
22 }
23 A sample test:
25 # t/sample.t
27 use MyProject::Test;
28 plan tests => 1 * blocks;
30 run_is input => 'expected';
32 sub local_filter {
34 s/my/your/;
35 }
36 __END__
38 === Test one (the name of the test)
40 --- input my_filter local_filter
41 my
42 input
43 lines
44 --- expected
45 expected
46 output
47 === Test two
49 This is an optional description
50 of this particular test.
51 --- input my_filter
52 other
53 input
54 lines
55 --- expected
56 other expected
57 output
58
60 Testing is usually the ugly part of Perl module authoring. Perl gives
61 you a standard way to run tests with Test::Harness, and basic testing
62 primitives with Test::More. After that you are pretty much on your own
63 to develop a testing framework and philosophy. Test::More encourages
64 you to make your own framework by subclassing Test::Builder, but that
65 is not trivial.
66 Test::Base gives you a way to write your own test framework base class
68 that is trivial. In fact it is as simple as two lines:
69 package MyTestFramework;
71 use Test::Base -Base;
72 A module called "MyTestFramework.pm" containing those two lines, will
74 give all the power of Test::More and all the power of Test::Base to
75 every test file that uses it. As you build up the capabilities of
76 "MyTestFramework", your tests will have all of that power as well.
77 "MyTestFramework" becomes a place for you to put all of your reusable
79 testing bits. As you write tests, you will see patterns and duplica‐
80 tion, and you can "upstream" them into "MyTestFramework". Of course,
81 you don't have to subclass Test::Base at all. You can use it directly
82 in many applications, including everywhere you would use Test::More.
83 Test::Base concentrates on offering reusable data driven patterns, so
85 that you can write tests with a minimum of code. At the heart of all
86 testing you have inputs, processes and expected outputs. Test::Base
87 provides some clean ways for you to express your input and expected
88 output data, so you can spend your time focusing on that rather than
89 your code scaffolding.
90
92 Test::Base extends Test::More and exports all of its functions. So you
93 can basically write your tests the same as Test::More. Test::Base also
94 exports many functions of its own:
95 is(actual, expected, [test-name])
97 This is the equivalent of Test::More's "is" function with one interest‐
99 ing twist. If your actual and expected results differ and the output is
100 multi-line, this function will show you a unified diff format of out‐
101 put. Consider the benefit when looking for the one character that is
102 different in hundreds of lines of output!
103 Diff output requires the optional "Text::Diff" CPAN module. If you
105 don't have this module, the "is()" function will simply give you normal
106 Test::More output. To disable diffing altogether, set the
107 "TEST_SHOW_NO_DIFFS" environment variable (or $ENV{TEST_SHOW_NO_DIFFS})
108 to a true value. You can also call the "no_diff" function as a short‐
109 cut.
110 blocks( [data-section-name] )
112 The most important function is "blocks". In list context it returns a
114 list of "Test::Base::Block" objects that are generated from the test
115 specification in the "DATA" section of your test file. In scalar con‐
116 text it returns the number of objects. This is useful to calculate your
117 Test::More plan.
118 Each Test::Base::Block object has methods that correspond to the names
120 of that object's data sections. There is also a "name" and a "descrip‐
121 tion" method for accessing those parts of the block if they were speci‐
122 fied.
123 The "blocks" function can take an optional single argument, that indi‐
125 cates to only return the blocks that contain a particular named data
126 section. Otherwise "blocks" returns all blocks.
127 my @all_of_my_blocks = blocks;
129 my @just_the_foo_blocks = blocks('foo');
131 next_block()
133 You can use the next_block function to iterate over all the blocks.
135 while (my $block = next_block) {
137 ...
138 }
139 It returns undef after all blocks have been iterated over. It can then
141 be called again to reiterate.
142 first_block()
144 Returns the first block or undef if there are none. It resets the iter‐
146 ator to the "next_block" function.
147 run(&subroutine)
149 There are many ways to write your tests. You can reference each block
151 individually or you can loop over all the blocks and perform a common
152 operation. The "run" function does the looping for you, so all you need
153 to do is pass it a code block to execute for each block.
154 The "run" function takes a subroutine as an argument, and calls the sub
156 one time for each block in the specification. It passes the current
157 block object to the subroutine.
158 run {
160 my $block = shift;
161 is(process($block->foo), $block->bar, $block->name);
162 };
163 run_is([data_name1, data_name2])
165 Many times you simply want to see if two data sections are equivalent
167 in every block, probably after having been run through one or more fil‐
168 ters. With the "run_is" function, you can just pass the names of any
169 two data sections that exist in every block, and it will loop over
170 every block comparing the two sections.
171 run_is 'foo', 'bar';
173 If no data sections are given "run_is" will try to detect them automat‐
175 ically.
176 NOTE: Test::Base will silently ignore any blocks that don't contain
178 both sections.
179 run_is_deeply([data_name1, data_name2])
181 Like "run_is" but uses "is_deeply" for complex data structure compari‐
183 son.
184 run_like([data_name, regexp ⎪ data_name]);
186 The "run_like" function is similar to "run_is" except the second argu‐
188 ment is a regular expression. The regexp can either be a "qr{}" object
189 or a data section that has been filtered into a regular expression.
190 run_like 'foo', qr{<html.*};
192 run_like 'foo', 'match';
193 run_unlike([data_name, regexp ⎪ data_name]);
195 The "run_unlike" function is similar to "run_like", except the oppo‐
197 site.
198 run_unlike 'foo', qr{<html.*};
200 run_unlike 'foo', 'no_match';
201 run_compare(data_name1, data_name2)
203 The "run_compare" function is like the "run_is", "run_is_deeply" and
205 the "run_like" functions all rolled into one. It loops over each rele‐
206 vant block and determines what type of comparison to do.
207 NOTE: If you do not specify either a plan, or run any tests, the
209 "run_compare" function will automatically be run.
210 delimiters($block_delimiter, $data_delimiter)
212 Override the default delimiters of "===" and "---".
214 spec_file($file_name)
216 By default, Test::Base reads its input from the DATA section. This
218 function tells it to get the spec from a file instead.
219 spec_string($test_data)
221 By default, Test::Base reads its input from the DATA section. This
223 function tells it to get the spec from a string that has been prepared
224 somehow.
225 filters( @filters_list or $filters_hashref )
227 Specify a list of additional filters to be applied to all blocks. See
229 FILTERS below.
230 You can also specify a hash ref that maps data section names to an
232 array ref of filters for that data type.
233 filters {
235 xxx => [qw(chomp lines)],
236 yyy => ['yaml'],
237 zzz => 'eval',
238 };
239 If a filters list has only one element, the array ref is optional.
241 filters_delay( [1 ⎪ 0] );
243 By default Test::Base::Block objects are have all their filters run
245 ahead of time. There are testing situations in which it is advantageous
246 to delay the filtering. Calling this function with no arguments or a
247 true value, causes the filtering to be delayed.
248 use Test::Base;
250 filters_delay;
251 plan tests => 1 * blocks;
252 for my $block (blocks) {
253 ...
254 $block->run_filters;
255 ok($block->is_filtered);
256 ...
257 }
258 In the code above, the filters are called manually, using the "run_fil‐
260 ters" method of Test::Base::Block. In functions like "run_is", where
261 the tests are run automatically, filtering is delayed until right
262 before the test.
263 filter_arguments()
265 Return the arguments after the equals sign on a filter.
267 sub my_filter {
269 my $args = filter_arguments;
270 # is($args, 'whazzup');
271 ...
272 }
273 __DATA__
275 === A test
276 --- data my_filter=whazzup
277 tie_output()
279 You can capture STDOUT and STDERR for operations with this function:
281 my $out = '';
283 tie_output(*STDOUT, $buffer);
284 print "Hey!\n";
285 print "Che!\n";
286 untie *STDOUT;
287 is($out, "Hey!\nChe!\n");
288 no_diff()
290 Turn off diff support for is() in a test file.
292 default_object()
294 Returns the default Test::Base object. This is useful if you feel the
296 need to do an OO operation in otherwise functional test code. See OO
297 below.
298 WWW() XXX() YYY() ZZZ()
300 These debugging functions are exported from the Spiffy.pm module. See
302 Spiffy for more info.
303 croak() carp() cluck() confess()
305 You can use the functions from the Carp module without needing to
307 import them. Test::Base does it for you by default.
308
310 Test::Base allows you to specify your test data in an external file,
311 the DATA section of your program or from a scalar variable containing
312 all the text input.
313 A test specification is a series of text lines. Each test (or block) is
315 separated by a line containing the block delimiter and an optional test
316 "name". Each block is further subdivided into named sections with a
317 line containing the data delimiter and the data section name. A
318 "description" of the test can go on lines after the block delimiter but
319 before the first data section.
320 Here is the basic layout of a specification:
322 === <block name 1>
324 <optional block description lines>
325 --- <data section name 1> <filter-1> <filter-2> <filter-n>
326 <test data lines>
327 --- <data section name 2> <filter-1> <filter-2> <filter-n>
328 <test data lines>
329 --- <data section name n> <filter-1> <filter-2> <filter-n>
330 <test data lines>
331 === <block name 2>
333 <optional block description lines>
334 --- <data section name 1> <filter-1> <filter-2> <filter-n>
335 <test data lines>
336 --- <data section name 2> <filter-1> <filter-2> <filter-n>
337 <test data lines>
338 --- <data section name n> <filter-1> <filter-2> <filter-n>
339 <test data lines>
340 Here is a code example:
342 use Test::Base;
344 delimiters qw(### :::);
346 # test code here
348 __END__
350 ### Test One
352 We want to see if foo and bar
353 are really the same...
354 ::: foo
355 a foo line
356 another foo line
357 ::: bar
359 a bar line
360 another bar line
361 ### Test Two
363 ::: foo
365 some foo line
366 some other foo line
367 ::: bar
369 some bar line
370 some other bar line
371 ::: baz
373 some baz line
374 some other baz line
375 This example specifies two blocks. They both have foo and bar data sec‐
377 tions. The second block has a baz component. The block delimiter is
378 "###" and the data delimiter is ":::".
379 The default block delimiter is "===" and the default data delimiter is
381 "---".
382 There are some special data section names used for control purposes:
384 --- SKIP
386 --- ONLY
387 --- LAST
388 A block with a SKIP section causes that test to be ignored. This is
390 useful to disable a test temporarily.
391 A block with an ONLY section causes only that block to be used. This is
393 useful when you are concentrating on getting a single test to pass. If
394 there is more than one block with ONLY, the first one will be chosen.
395 Because ONLY is very useful for debugging and sometimes you forgot to
397 remove the ONLY flag before commiting to the VCS or uploading to CPAN,
398 Test::Base by default gives you a diag message saying I found ONLY ...
399 maybe you're debugging?. If you don't like it, use "no_diag_on_only".
400 A block with a LAST section makes that block the last one in the speci‐
402 fication. All following blocks will be ignored.
403
405 The real power in writing tests with Test::Base comes from its filter‐
406 ing capabilities. Test::Base comes with an ever growing set of useful
407 generic filters than you can sequence and apply to various test blocks.
408 That means you can specify the block serialization in the most readable
409 format you can find, and let the filters translate it into what you
410 really need for a test. It is easy to write your own filters as well.
411 Test::Base allows you to specify a list of filters to each data section
413 of each block. The default filters are "norm" and "trim". These fil‐
414 ters will be applied (in order) to the data after it has been parsed
415 from the specification and before it is set into its Test::Base::Block
416 object.
417 You can add to the default filter list with the "filters" function. You
419 can specify additional filters to a specific block by listing them
420 after the section name on a data section delimiter line.
421 Example:
423 use Test::Base;
425 filters qw(foo bar);
427 filters { perl => 'strict' };
428 sub upper { uc(shift) }
430 __END__
432 === Test one
434 --- foo trim chomp upper
435 ...
436 --- bar -norm
438 ...
439 --- perl eval dumper
441 my @foo = map {
442 - $_;
443 } 1..10;
444 \ @foo;
445 Putting a "-" before a filter on a delimiter line, disables that fil‐
447 ter.
448 Scalar vs List
450 Each filter can take either a scalar or a list as input, and will
452 return either a scalar or a list. Since filters are chained together,
453 it is important to learn which filters expect which kind of input and
454 return which kind of output.
455 For example, consider the following filter list:
457 norm trim lines chomp array dumper eval
459 The data always starts out as a single scalar string. "norm" takes a
461 scalar and returns a scalar. "trim" takes a list and returns a list,
462 but a scalar is a valid list. "lines" takes a scalar and returns a
463 list. "chomp" takes a list and returns a list. "array" takes a list and
464 returns a scalar (an anonymous array reference containing the list ele‐
465 ments). "dumper" takes a list and returns a scalar. "eval" takes a
466 scalar and creates a list.
467 A list of exactly one element works fine as input to a filter requiring
469 a scalar, but any other list will cause an exception. A scalar in list
470 context is considered a list of one element.
471 Data accessor methods for blocks will return a list of values when used
473 in list context, and the first element of the list in scalar context.
474 This is usually "the right thing", but be aware.
475 The Stock Filters
477 Test::Base comes with large set of stock filters. They are in the
479 "Test::Base::Filter" module. See Test::Base::Filter for a listing and
480 description of these filters.
481 Rolling Your Own Filters
483 Creating filter extensions is very simple. You can either write a func‐
485 tion in the "main" namespace, or a method in the "Test::Base::Filter"
486 namespace or a subclass of it. In either case the text and any extra
487 arguments are passed in and you return whatever you want the new value
488 to be.
489 Here is a self explanatory example:
491 use Test::Base;
493 filters 'foo', 'bar=xyz';
495 sub foo {
497 transform(shift);
498 }
499 sub Test::Base::Filter::bar {
501 my $self = shift; # The Test::Base::Filter object
502 my $data = shift;
503 my $args = $self->current_arguments;
504 my $current_block_object = $self->block;
505 # transform $data in a barish manner
506 return $data;
507 }
508 If you use the method interface for a filter, you can access the block
510 internals by calling the "block" method on the filter object.
511 Normally you'll probably just use the functional interface, although
513 all the builtin filters are methods.
514 Note that filters defined in the "main" namespace can look like:
516 sub filter9 {
518 s/foo/bar/;
519 }
520 since Test::Base automatically munges the input string into $_ variable
522 and checks the return value of the function to see if it looks like a
523 number. If you must define a filter that returns just a single number,
524 do it in a different namespace as a method. These filters don't allow
525 the simplistic $_ munging.
526
528 Test::Base has a nice functional interface for simple usage. Under the
529 hood everything is object oriented. A default Test::Base object is cre‐
530 ated and all the functions are really just method calls on it.
531 This means if you need to get fancy, you can use all the object ori‐
533 ented stuff too. Just create new Test::Base objects and use the func‐
534 tions as methods.
535 use Test::Base;
537 my $blocks1 = Test::Base->new;
538 my $blocks2 = Test::Base->new;
539 $blocks1->delimiters(qw(!!! @@@))->spec_file('test1.txt');
541 $blocks2->delimiters(qw(### $$$))->spec_string($test_data);
542 plan tests => $blocks1->blocks + $blocks2->blocks;
544 # ... etc
546
548 In Test::Base, blocks are exposed as Test::Base::Block objects. This
549 section lists the methods that can be called on a Test::Base::Block
550 object. Of course, each data section name is also available as a
551 method.
552 name()
554 This is the optional short description of a block, that is specified on
556 the block separator line.
557 description()
559 This is an optional long description of the block. It is the text taken
561 from between the block separator and the first data section.
562 seq_num()
564 Returns a sequence number for this block. Sequence numbers begin with
566 1.
567 blocks_object()
569 Returns the Test::Base object that owns this block.
571 run_filters()
573 Run the filters on the data sections of the blocks. You don't need to
575 use this method unless you also used the "filters_delay" function.
576 is_filtered()
578 Returns true if filters have already been run for this block.
580 original_values()
582 Returns a hash of the original, unfiltered values of each data section.
584
586 One of the nicest things about Test::Base is that it is easy to sub‐
587 class. This is very important, because in your personal project, you
588 will likely want to extend Test::Base with your own filters and other
589 reusable pieces of your test framework.
590 Here is an example of a subclass:
592 package MyTestStuff;
594 use Test::Base -Base;
595 our @EXPORT = qw(some_func);
597 sub some_func {
599 (my ($self), @_) = find_my_self(@_);
600 ...
601 }
602 package MyTestStuff::Block;
604 use base 'Test::Base::Block';
605 sub desc {
607 $self->description(@_);
608 }
609 package MyTestStuff::Filter;
611 use base 'Test::Base::Filter';
612 sub upper {
614 $self->assert_scalar(@_);
615 uc(shift);
616 }
617 Note that you don't have to re-Export all the functions from
619 Test::Base. That happens automatically, due to the powers of Spiffy.
620 The first line in "some_func" allows it to be called as either a func‐
622 tion or a method in the test code.
623
625 You might be thinking that you do not want to use Test::Base in you
626 modules, because it adds an installation dependency. Fear not. Mod‐
627 ule::Install takes care of that.
628 Just write a Makefile.PL that looks something like this:
630 use inc::Module::Install;
632 name 'Foo';
634 all_from 'lib/Foo.pm';
635 use_test_base;
637 WriteAll;
639 The line with "use_test_base" will automatically bundle all the code
641 the user needs to run Test::Base based tests.
642
644 Test::Base automatically adds:
645 use strict;
647 use warnings;
648 to all of your test scripts and Test::Base subclasses. A Spiffy feature
650 indeed.
651
653 This module started its life with the horrible and ridicule inducing
654 name "Test::Chunks". It was renamed to "Test::Base" with the hope that
655 it would be seen for the very useful module that it has become. If you
656 are switching from "Test::Chunks" to "Test::Base", simply substitute
657 the concept and usage of "chunks" to "blocks".
658
660 Ingy döt Net <ingy@cpan.org>
661
663 Copyright (c) 2006. Ingy döt Net. All rights reserved. Copyright (c)
664 2005. Brian Ingerson. All rights reserved.
665 This program is free software; you can redistribute it and/or modify it
667 under the same terms as Perl itself.
668 See http://www.perl.com/perl/misc/Artistic.html
670perl v5.8.8 2006-08-26 Test::Base(3)