名前¶

Test::Base - データドリブンのテストフレームワーク

概要¶

A new test module:

新しいテストモジュール:

    # lib/MyProject/Test.pm
    package MyProject::Test;
    use Test::Base -Base;
    
    use MyProject;
    
    package MyProject::Test::Filter;
    use Test::Base::Filter -base;

    sub my_filter {
        return MyProject->do_something(shift);
    }

A sample test:

テストの例:

    # t/sample.t
    use MyProject::Test;
    
    plan tests => 1 * blocks;
    
    run_is input => 'expected';

    sub local_filter {
        s/my/your/;
    }
    
    __END__
    
    === Test one (the name of the test)
    --- input my_filter local_filter
    my
    input
    lines
    --- expected
    expected
    output
    
    === Test two
    This is an optional description
    of this particular test.
    --- input my_filter
    other
    input
    lines
    --- expected
    other expected
    output

説明¶

Testing is usually the ugly part of Perl module authoring. Perl gives you a standard way to run tests with Test::Harness, and basic testing primitives with Test::More. After that you are pretty much on your own to develop a testing framework and philosophy. Test::More encourages you to make your own framework by subclassing Test::Builder, but that is not trivial.

Perlモジュールを書く上で、醜いのはたいていテストのところです。Perlには 標準のやりかたとして、Test::Harnesがあります。基本的で原始的なテストは Test::Moreで行えます。その後で、テストフレームワークと哲学を開発するために あなたはほとんど一人でいます(訳註:謎)。Test::MoreはTest::Builderを サブクラスにして、自分自身のフレームワークを作ることを推奨しています。 ですが、それは簡単なことではありません。

Test::Base gives you a way to write your own test framework base class that is trivial. In fact it is as simple as two lines:

Test::Base を使うと、自分用の取るにたらないテストフレームワークの ベースクラスを書くことができます。実際、以下の2行でできるくらい簡単です:

    package MyTestFramework;
    use Test::Base -Base;

A module called MyTestFramework.pm containing those two lines, will give all the power of Test::More and all the power of Test::Base to every test file that uses it. As you build up the capabilities of MyTestFramework, your tests will have all of that power as well.

この2行からなるMyTestFrameworkと呼ばれるモジュールは、 これを使う全てのテストファイルに、Test::Moreの全ての力と、 Test::Baseの全ての力を与えます。MyTestFrameworkの能力を高めるにつれ、 あなたのテストも同様にその力の全てを持つでしょう。

MyTestFramework becomes a place for you to put all of your reusable testing bits. As you write tests, you will see patterns and duplication, and you can "upstream" them into MyTestFramework. Of course, you don't have to subclass Test::Base at all. You can use it directly in many applications, including everywhere you would use Test::More.

MyTestFrameworkは再利用可能なテストの全てを置く場所になります。 テストを書くにつれ、パターンや重複を見かけて、それらをMyTestFrameworkに "上流"に出来るでしょう。もちろん、Test::Baseをサブクラスにしなければ いけないわけでは全然ありません。多くのアプリケーションで、Test::Baseを 直接使うことが出来ますし、Test::Moreを使っているどこにでもTest::Baseを 使うことが出来ます。

Test::Base concentrates on offering reusable data driven patterns, so that you can write tests with a minimum of code. At the heart of all testing you have inputs, processes and expected outputs. Test::Base provides some clean ways for you to express your input and expected output data, so you can spend your time focusing on that rather than your code scaffolding.

Test::Baseは再利用可能なデータドリブンなパターンを提供するのに 集中しています。そのため、最小限のコードでテストを書けます。 全てのテストの中心に、入力、処理、期待される出力があります。 Test::Baseには、入力と期待される値を表すのに簡単な方法があります。 そのため、コードの足場作りではなくて、中心のことに集中できます。

エクスポートされる関数¶

Test::Base extends Test::More and exports all of its functions. So you can basically write your tests the same as Test::More. Test::Base also exports many functions of its own:

Test::BaseはTest::Moreを継承しており、Test::Moreの全ての関数を エクスポートしています。そのため、基本的に、Test::Moreと同じように テストを書くことが出来ます。Test::Baseもまた、それ自身の多くの関数を エクスポートしています。

is(actual, expected, [test-name])¶

This is the equivalent of Test::More's is function with one interesting twist. If your actual and expected results differ and the output is multi-line, this function will show you a unified diff format of output. Consider the benefit when looking for the one character that is different in hundreds of lines of output!

Test::Moreのis関数と同等ですが、一ひねり加えています。 実際と期待する結果が違っており、出力が複数行にわたる場合、 この関数は、出力を unified diffフォーマット(訳註: diff -u)で表示します。 一文字違うだけなのに、数百行の出力が出ても嬉しくないでしょ！

Diff output requires the optional Text::Diff CPAN module. If you don't have this module, the is() function will simply give you normal Test::More output. To disable diffing altogether, set the TEST_SHOW_NO_DIFFS environment variable (or $ENV{TEST_SHOW_NO_DIFFS}) to a true value. You can also call the no_diff function as a shortcut.

Diff出力はオプションで、CPANモジュールのText::Diffが必要です。 このモジュールがなければ、is()関数は単純に、通常のTest::Moreの 出力を表示します。diffを完全に無効にしたいなら、TEST_SHOW_NO_DIFFS環境変数 (または、$ENV{TEST_SHOW_NO_DIFFS})に真の値を入れてください。 ショートカットとして、no_diff関数も使えます。

blocks( [data-section-name] )¶

The most important function is blocks. In list context it returns a list of Test::Base::Block objects that are generated from the test specification in the DATA section of your test file. In scalar context it returns the number of objects. This is useful to calculate your Test::More plan.

一番重要な関数は、blocksです。リストコンテキストでは、 テストファイルのDATAセクション以下にあるテスト仕様から生成された、 Test::Base::Blockオブジェクトのリストを返します。 スカラコンテキストでは、オブジェクトの数を返します。 Test::Moreのプランを数えるのに便利です。

Each Test::Base::Block object has methods that correspond to the names of that object's data sections. There is also a name and a description method for accessing those parts of the block if they were specified.

それぞれのTest::Base::Blockオブジェクトには、オブジェクトのデータセクション の名前に対応するメソッドがあります。それらが指定されていれば、 ブロックのそれらの部分にアクセスするために、nameとdescription メソッドもあります。

The blocks function can take an optional single argument, that indicates to only return the blocks that contain a particular named data section. Otherwise blocks returns all blocks.

blocks関数はオプションで一つの引数を取り、 特定の名前のデータセクションを含むブロックだけを返すように出来ます。 一方、blocksは全てのブロックを返します。

    my @all_of_my_blocks = blocks;

    my @just_the_foo_blocks = blocks('foo');

next_block()¶

You can use the next_block function to iterate over all the blocks.

全てのブロックをイテレートするnext_block関数もあります。

    while (my $block = next_block) {
        ...
    }

It returns undef after all blocks have been iterated over. It can then be called again to reiterate.

全てのブロックがイテレートされた後では、undefを返します。 もう一度呼べば、再度イテレートされます。

first_block()¶

Returns the first block or undef if there are none. It resets the iterator to the next_block function.

最初のブロックを返します。ブロックがなければ、undefを返します。 これで、next_block関数のイテレーターをリセットできます。

run(&subroutine)¶

There are many ways to write your tests. You can reference each block individually or you can loop over all the blocks and perform a common operation. The run function does the looping for you, so all you need to do is pass it a code block to execute for each block.

テストを書くにはたくさんの方法があります。全てのブロックを別々に 参照することも出来るし、全てのブロックをループすることも出来るし、 共通の操作をすることも出来ます。このrun関数はループするので、 それぞれのブロックに実行するコードブロックを渡すだけで構いません。

The run function takes a subroutine as an argument, and calls the sub one time for each block in the specification. It passes the current block object to the subroutine.

run関数は、引数として関数をとります。仕様にあるそれぞれのブロックごとに 関数を一回呼びます。現在のブロックオブジェクトにサブルーチンを渡しています。

    run {
        my $block = shift;
        is(process($block->foo), $block->bar, $block->name);
    };

run_is([data_name1, data_name2])¶

Many times you simply want to see if two data sections are equivalent in every block, probably after having been run through one or more filters. With the run_is function, you can just pass the names of any two data sections that exist in every block, and it will loop over every block comparing the two sections.

何回も、単純に全てのブロックで、おそらく一つかそれ以上のフィルターを 通した後で、2つのデータセクションが同等であるかどうかを見たいと思います。 run_is関数で、全てのブロックにある、いずれか2つのデータセクションの 名前を渡すだけで、全てのブロックをループして、二つのセクションを比較します。

    run_is 'foo', 'bar';

If no data sections are given run_is will try to detect them automatically.

データセクションを与えなれば、run_isは自動的に見付けようとします。

NOTE: Test::Base will silently ignore any blocks that don't contain both sections.

注意: Test::Baseは、両方のセクションを含んでいないブロックは暗黙に 無視します。

run_is_deeply([data_name1, data_name2])¶

Like run_is but uses is_deeply for complex data structure comparison.

run_isと似ていますが、複雑なデータの比較のためにis_deeplyを使います。

run_like([data_name, regexp | data_name]);¶

The run_like function is similar to run_is except the second argument is a regular expression. The regexp can either be a qr{} object or a data section that has been filtered into a regular expression.

run_like関数は、run_isに似ていますが、二番目の引数が 正規表現であるところが違います。正規表現は、qr{}オブジェクトか、 正規表現にフィルターされるデータセクションのどちらも取れます。

    run_like 'foo', qr{<html.*};
    run_like 'foo', 'match';

run_unlike([data_name, regexp | data_name]);¶

The run_unlike function is similar to run_like, except the opposite.

run_unlike関数はrun_likeと似ていますが、その反対です。

    run_unlike 'foo', qr{<html.*};
    run_unlike 'foo', 'no_match';

run_compare(data_name1, data_name2)¶

The run_compare function is like the run_is, run_is_deeply and the run_like functions all rolled into one. It loops over each relevant block and determines what type of comparison to do.

run_compare関数はrun_is、run_is_deeply、run_likeと似ていますが、 これら全てを一つにした関数です。それぞれ関連するブロックをループし、 どの種類の比較をするかを決定します。

NOTE: If you do not specify either a plan, or run any tests, the run_compare function will automatically be run.

注意: もしプランを指定しなければ、全てのテストを実行します。 run_compare関数は自動的に実行されます。

delimiters($block_delimiter, $data_delimiter)¶

Override the default delimiters of === and ---.

デフォルトのデリミタ===と---をオーバーライドします。

spec_file($file_name)¶

By default, Test::Base reads its input from the DATA section. This function tells it to get the spec from a file instead.

デフォルトでは、Test::Baseは、DATAセクションから入力を読みます。 この関数は、その代わりに、ファイルから仕様を読むようにします。

spec_string($test_data)¶

By default, Test::Base reads its input from the DATA section. This function tells it to get the spec from a string that has been prepared somehow.

デフォルトでは、Test::Baseは、DATAセクションから入力を読みます。 この関数は、何かして準備している文字列から仕様を得るようにします。

filters( @filters_list or $filters_hashref )¶

Specify a list of additional filters to be applied to all blocks. See FILTERS below.

全てのブロックに適用するフィルターをリストに追加します。 後述のFILTERSを見てください。

You can also specify a hash ref that maps data section names to an array ref of filters for that data type.

ハッシュリファレンスで、データーセクションの名前にフィルターの配列 リファレンスをマッピングすることもできます。

    filters {
        xxx => [qw(chomp lines)],
        yyy => ['yaml'],
        zzz => 'eval',
    };

If a filters list has only one element, the array ref is optional.

フィルターリストが一要素しかなければ、配列リファレンスでなくても かまいません。

filters_delay( [1 | 0] );¶

By default Test::Base::Block objects are have all their filters run ahead of time. There are testing situations in which it is advantageous to delay the filtering. Calling this function with no arguments or a true value, causes the filtering to be delayed.

デフォルトでは、Test::Base::Blockオブジェクトは、そのフィルターを 前もって実行しています。シチュエーションによっては、フィルタリングを 遅らせたほうが都合が良いこともあります。この関数を引数なしで呼ぶか、 真の値を引数に呼ぶと、フィルタリングは遅れて実行されます。

    use Test::Base;
    filters_delay;
    plan tests => 1 * blocks;
    for my $block (blocks) {
        ...
        $block->run_filters;
        ok($block->is_filtered);
        ...
    }

In the code above, the filters are called manually, using the run_filters method of Test::Base::Block. In functions like run_is, where the tests are run automatically, filtering is delayed until right before the test.

上記のようなコードで、フィルターは手動で呼ばれます。 Test::Base::Blockのrun_filtersメソッドを使います。 run_isのような関数で、テストが自動的に実行される場所で、 そのテストの前まで、フィルタリングが遅らされます。

filter_arguments()¶

Return the arguments after the equals sign on a filter.

フィルタの等号の後ろの引数を返します。

    sub my_filter {
        my $args = filter_arguments;
        # is($args, 'whazzup');
        ...
    }

    __DATA__
    === A test
    --- data my_filter=whazzup

tie_output()¶

You can capture STDOUT and STDERR for operations with this function:

この関数で、STDOUTとSTDERRをキャプチャできます:

    my $out = '';
    tie_output(*STDOUT, $buffer);
    print "Hey!\n";
    print "Che!\n";
    untie *STDOUT;
    is($out, "Hey!\nChe!\n");

no_diff()¶

Turn off diff support for is() in a test file.

テストファイルの中のis()のdiffサポートをオフにします。

default_object()¶

Returns the default Test::Base object. This is useful if you feel the need to do an OO operation in otherwise functional test code. See OO below.

デフォルトのTest::Baseオブジェクトを返します。 関数的なテストコードではなく、OO的なオペレーションをしたいなら、便利です。 後述のOOを見てください。

WWW() XXX() YYY() ZZZ()¶

These debugging functions are exported from the Spiffy.pm module. See Spiffy for more info.

Spiffy.pm モジュールからエクスポートされたデバッギング関数です。 詳細はSpiffyを見てください。

croak() carp() cluck() confess()¶

You can use the functions from the Carp module without needing to import them. Test::Base does it for you by default.

インポートすることなく、Carpモジュールの関数を使えます。Test::Base はデフォルトで、インポートします。

テストの仕様¶

Test::Base allows you to specify your test data in an external file, the DATA section of your program or from a scalar variable containing all the text input.

Test::Baseでは、全てのテキスト入力を含んだテストデータの指定を、 外部ファイルか、プログラムのDATAセクション内か、またはスカラーからか、 指定できます。

A test specification is a series of text lines. Each test (or block) is separated by a line containing the block delimiter and an optional test name. Each block is further subdivided into named sections with a line containing the data delimiter and the data section name. A description of the test can go on lines after the block delimiter but before the first data section.

テストの仕様は一連のテキスト行です。互いのテスト(かブロック)は ブロックの区切りとオプションのテストのnameを含む行によって 分けられています。それぞれのブロックはデータデリミタとデータ セクション名を含んだ名前つきのセクションにさらに分けられます。 テストのdescriptionはブロックデリミタの後に続けられますが、 最初のデータセクションの前に書きます。

Here is the basic layout of a specification:

仕様の基本的なレイアウトです:

    === <block name 1>
    <optional block description lines>
    --- <data section name 1> <filter-1> <filter-2> <filter-n>
    <test data lines>
    --- <data section name 2> <filter-1> <filter-2> <filter-n>
    <test data lines>
    --- <data section name n> <filter-1> <filter-2> <filter-n>
    <test data lines>

    === <block name 2>
    <optional block description lines>
    --- <data section name 1> <filter-1> <filter-2> <filter-n>
    <test data lines>
    --- <data section name 2> <filter-1> <filter-2> <filter-n>
    <test data lines>
    --- <data section name n> <filter-1> <filter-2> <filter-n>
    <test data lines>

Here is a code example:

コードの例です:

    use Test::Base;
    
    delimiters qw(### :::);

    # test code here

    __END__
    
    ### Test One
    We want to see if foo and bar
    are really the same... 
    ::: foo
    a foo line
    another foo line

    ::: bar
    a bar line
    another bar line

    ### Test Two
    
    ::: foo
    some foo line
    some other foo line
    
    ::: bar
    some bar line
    some other bar line

    ::: baz
    some baz line
    some other baz line

This example specifies two blocks. They both have foo and bar data sections. The second block has a baz component. The block delimiter is ### and the data delimiter is :::.

この例では二つのブロックを指定しています。ブロックには、 fooとbarのデータセクションがあります。二番目のブロックには、 bazコンポーネントがあります。ブロックのデリミタは、###で、 データのデリミタは:::です。

The default block delimiter is === and the default data delimiter is ---.

デフォルトのブロックデリミタは===で、デフォルトのデータデリミタは、 ---です。

There are some special data section names used for control purposes:

データセクションの名前には、特別な名前があり、テストをコントロールするために使います:

    --- SKIP
    --- ONLY
    --- LAST

A block with a SKIP section causes that test to be ignored. This is useful to disable a test temporarily.

SKIPついたのブロックセクションはテストを無視します。一時的にテストを 無功にするのに便利です。

A block with an ONLY section causes only that block to be used. This is useful when you are concentrating on getting a single test to pass. If there is more than one block with ONLY, the first one will be chosen.

ONLYをブロックに付けると、そのブロックだけが使われます。 一つのテストをパスするのに集中したい時に便利です。 一つ以上のONLYブロックがある場合、最初のものが選ばれます。

A block with a LAST section makes that block the last one in the specification. All following blocks will be ignored.

LASTのついたブロックセクションは、そのブロックを仕様の最後のものにします。 後に続くブロックは無視されます。

FILTERS¶

The real power in writing tests with Test::Base comes from its filtering capabilities. Test::Base comes with an ever growing set of useful generic filters than you can sequence and apply to various test blocks. That means you can specify the block serialization in the most readable format you can find, and let the filters translate it into what you really need for a test. It is easy to write your own filters as well.

Test::Baseでテストを書くときに、本当に力になるのは、そのフィルタリング 能力です。Test::Baseにはさまざまなテストブロックに順序付けて適用できる (訳註: thanとあるがthatじゃないかな?)、これまでに増え続けている便利な 一般的なフィルタのセットが付属します。このことは、あなたが見つけられる、 もっとも可読性の高いフォーマットでブロックシリアリゼィションを指定でき、 フィルタでそれを本当にテストに必要なものに変換させることができるということです。 おまけに、自分自身のフィルタを書くのも簡単です。

Test::Base allows you to specify a list of filters to each data section of each block. The default filters are norm and trim. These filters will be applied (in order) to the data after it has been parsed from the specification and before it is set into its Test::Base::Block object.

Test::Baseでは、それぞれのブロックのそれぞれのデータセクションへの フィルタのリストを特定できます。デフォルトのフィルタは、normとtrimです。 Test::Base::Blockオブジェクトにセットされる前に、仕様からパースされた後、 これらのフィルタは(順番に)データに適用されます。

You can add to the default filter list with the filters function. You can specify additional filters to a specific block by listing them after the section name on a data section delimiter line.

filters関数でデフォルトのフィルターのリストに加えることが出来ます。 データセクションのデリミタ行に、そのセクション名の後に、フィルタを リストすることで、特定のブロックに特定の追加的なフィルタを適用できます。

Example:

例:

    use Test::Base;

    filters qw(foo bar);
    filters { perl => 'strict' };

    sub upper { uc(shift) }

    __END__

    === Test one
    --- foo trim chomp upper
    ...

    --- bar -norm
    ...

    --- perl eval dumper
    my @foo = map {
        - $_;
    } 1..10;
    \ @foo;

Putting a - before a filter on a delimiter line, disables that filter.

デリミタ行にある、フィルタの前に-を置くと、フィルタを無効に出来ます。

スカラ vs リスト¶

Each filter can take either a scalar or a list as input, and will return either a scalar or a list. Since filters are chained together, it is important to learn which filters expect which kind of input and return which kind of output.

それぞれのフィルタは、入力として、スカラかリストを取り、スカラかリスト を返します。フィルタは一緒につながれるため、どのフィルタがどの種類の インプットを期待し、どの種類の出力を返すのかを知っておくことが重要です。

For example, consider the following filter list:

例えば、下記のフィルタリストを考えてみて下さい:

    norm trim lines chomp array dumper eval

The data always starts out as a single scalar string. norm takes a scalar and returns a scalar. trim takes a list and returns a list, but a scalar is a valid list. lines takes a scalar and returns a list. chomp takes a list and returns a list. array takes a list and returns a scalar (an anonymous array reference containing the list elements). dumper takes a list and returns a scalar. eval takes a scalar and creates a list.

データは常に、単一のスカラ文字列として始まります。normは スカラを取り、スカラを返します。trimはリストを取り、リストを返しますが、 スカラは正しいリストです。linesはスカラを取り、リストを返します。 chompはリストを取り、リストを返します。arrayはリストを取り、 スカラ(リスト要素を含んだ無名配列リファレンス)を返します。dumprはリストを 取り、スカラを返します。evalはスカラを取りリストを作ります。

A list of exactly one element works fine as input to a filter requiring a scalar, but any other list will cause an exception. A scalar in list context is considered a list of one element.

正確に一つの要素のリストは、スカラを必要とするフィルタへの入力として うまく動きます。ですが、他のどんなリスト(訳註:一つ以上の要素を持つ)も、 例外を起こします。リストコンテキストで一つのスカラは一つの要素のリスト として考えられます。

Data accessor methods for blocks will return a list of values when used in list context, and the first element of the list in scalar context. This is usually "the right thing", but be aware.

ブロックのデータアクセサメソッドは、リストコンテキストでは値のリストを返します。 スカラコンテキストではリストの最初の要素を返します。 これは、普通"正しいこと"ですが、気を付けてください。

The Stock Filters¶

Test::Base comes with large set of stock filters. They are in the Test::Base::Filter module. See Test::Base::Filter for a listing and description of these filters.

Test::Base には、ストックフィルタ多数のフィルタセットがあります。 Test::Base::Filterモジュールにあります。フィルタのリストと説明は Test::Base::Filterを見て下さい。

Rolling Your Own Filters¶

Creating filter extensions is very simple. You can either write a function in the main namespace, or a method in the Test::Base::Filter namespace or a subclass of it. In either case the text and any extra arguments are passed in and you return whatever you want the new value to be.

フィルタの拡張はとても簡単です。main名前空間にfunctionを書くか、 Test::Base::Filter名前空間か、そのサブクラスにmethodを書くことも できます。それぞれのケースで、テキストと付加的な引数が渡され、 新しい値として欲しいものを何でも返せます。

Here is a self explanatory example:

説明的な例:

    use Test::Base;

    filters 'foo', 'bar=xyz';

    sub foo {
        transform(shift);
    }
        
    sub Test::Base::Filter::bar {
        my $self = shift;       # The Test::Base::Filter object
        my $data = shift;
        my $args = $self->arguments;
        my $current_block_object = $self->block;
        # transform $data in a barish manner
        return $data;
    }

If you use the method interface for a filter, you can access the block internals by calling the block method on the filter object. Normally you'll probably just use the functional interface, although all the builtin filters are methods.

フィルタにメソッドインターフェースを使えば、フィルタオブジェクトで、 blockメソッドでを呼ぶことで、ブロックの内部にアクセスできます。 通常、おそらく関数インターフェースを使うでしょう。ですが、全ての 組み込みのフィルタはメソッドです。

OO¶

Test::Base has a nice functional interface for simple usage. Under the hood everything is object oriented. A default Test::Base object is created and all the functions are really just method calls on it.

Test::Baseは簡単に使える良い関数インターフェースがあります。 フードの下で、全てのものはオブジェクト指向です。デフォルトで Test::Baseオブジェクトは作られ、実際に全ての関数はメソッドで呼び出せます。

This means if you need to get fancy, you can use all the object oriented stuff too. Just create new Test::Base objects and use the functions as methods.

これは、fancyにならなければならないなら、全てのオブジェクト指向のものも 使うことが出来るということです。Test::Baseオブジェクトを新しく作って、 メソッドとして関数を使うだけです。

    use Test::Base;
    my $blocks1 = Test::Base->new;
    my $blocks2 = Test::Base->new;

    $blocks1->delimiters(qw(!!! @@@))->spec_file('test1.txt');
    $blocks2->delimiters(qw(### $$$))->spec_string($test_data);

    plan tests => $blocks1->blocks + $blocks2->blocks;

    # ... etc

Test::Base::Blockクラス¶

In Test::Base, blocks are exposed as Test::Base::Block objects. This section lists the methods that can be called on a Test::Base::Block object. Of course, each data section name is also available as a method.

Test::Baseには、Test::Base::Blockオブジェクトとして、blocksがexposeされています。 このセクションでは、Test::Base::Blockオブジェクトで呼べるメソッドを一覧します。 もちろん、それぞれのデータセクション名もまた、メソッドとして使えます。

name()¶

This is the optional short description of a block, that is specified on the block separator line.

blockのオプショナルな短い説明です。ブロックのセパレータの行に記入されます。

description()¶

This is an optional long description of the block. It is the text taken from between the block separator and the first data section.

blockのオプショナルな長い説明です。ブロックセパレータと最初のデータセパレータの 間に書かれているテキストです。

seq_num()¶

Returns a sequence number for this block. Sequence numbers begin with 1.

ブロックのシーケンス番号を返します。シーケンス番号は1から始まります。

blocks_object()¶

Returns the Test::Base object that owns this block.

このブロックを持っているTest::Baseオブジェクトを返します。

run_filters()¶

Run the filters on the data sections of the blocks. You don't need to use this method unless you also used the filters_delay function.

ブロックのデータセクションのフィルターを実行します。 filter_delay関数を使わなければ、このメソッドを使う必要はありません。

is_filtered()¶

Returns true if filters have already been run for this block.

このブロックで既にフィルターが実行されていれば、真を返します。

original_values()¶

Returns a hash of the original, unfiltered values of each data section.

それぞれのデータセクションのフィルターされていない、 オリジナルのハッシュを返します。

サブクラス化¶

One of the nicest things about Test::Base is that it is easy to subclass. This is very important, because in your personal project, you will likely want to extend Test::Base with your own filters and other reusable pieces of your test framework.

Test::Baseの一番良い機能の一つは、サブクラスを作るのが簡単なことです。 このことはとても重要です。自分の個人的なプロジェクトで、自分のテスト フレームワークの、自分自身のフィルターや他の再利用可能なもので、 おそらくTest::Baseを拡張したいでしょうから。

Here is an example of a subclass:

サプクラスの例です:

    package MyTestStuff;
    use Test::Base -Base;

    our @EXPORT = qw(some_func);

    sub some_func {
        (my ($self), @_) = find_my_self(@_);
        ...
    }

    package MyTestStuff::Block;
    use base 'Test::Base::Block';

    sub desc {
        $self->description(@_);
    }

    package MyTestStuff::Filter;
    use base 'Test::Base::Filter';

    sub upper {
        $self->assert_scalar(@_);
        uc(shift);
    }

Note that you don't have to re-Export all the functions from Test::Base. That happens automatically, due to the powers of Spiffy.

Test::Baseから全ての関数を再度エクスポートする必要はありません。 Spiffyの力で、自動的に行われます。

The first line in some_func allows it to be called as either a function or a method in the test code.

some_funcの最初の行で、テストコードで、関数かメソッドのどちらでも 呼べるようにしています。

配布サポート¶

You might be thinking that you do not want to use Test::Base in you modules, because it adds an installation dependency. Fear not. Module::Build takes care of that.

インストールに依存性を加えたくないので、自分のモジュールで Test::Baseを使いたくないと思うかもしれません。 恐れないでください。Module::Buildが面倒をみてくれます。

Just write a Makefile.PL that looks something like this:

Makefile.PLに、次のように書いてください:

    use inc::Module::Install;

    name            'Foo';
    all_from        'lib/Foo.pm';

    use_test_base;

    WriteAll;

The line with use_test_base will automatically bundle all the code the user needs to run Test::Base based tests.

use_test_baseの行が自動的に、Test::Baseに基づいているテストを実行するのに ユーザーが必要な全てのコードをバンドルします。

他のクールな機能¶

Test::Base automatically adds:

Test::Baseは自動的に追加します:

    use strict;
    use warnings;

to all of your test scripts and Test::Base subclasses. A Spiffy feature indeed.

全てのテストスクリプトとTest::Baseサブクラスに。実際には、Spiffy の機能です。

HISTORY¶

This module started its life with the horrible and ridicule inducing name Test::Chunks. It was renamed to Test::Base with the hope that it would be seen for the very useful module that it has become. If you are switching from Test::Chunks to Test::Base, simply substitute the concept and usage of chunks to blocks.

Test::Chunksという名前に含まれる、ひどいものと愚弄とでその命 を始めました。とても便利なモジュールになると分かることを望んで、 Test::Baseという名前に変更されました。 Test::ChunksからTest::Baseに変更するなら、単純に、 chunksのコンセプトと使い方の代わりに、blocksにしてください。

作者¶

Ingy döt Net <[email protected]>

コピーライト¶

Copyright (c) 2006. Ingy döt Net. All rights reserved. Copyright (c) 2005. Brian Ingerson. All rights reserved.

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

See http://www.perl.com/perl/misc/Artistic.html