Test-Simple-0.98 > Test::Tutorial

名前

Test::Tutorial - A tutorial about writing really basic tests

Test::Tutorial - ごく基本的なテストを書くことについてのチュートリアル

説明

AHHHHHHH!!!! NOT TESTING! Anything but testing! Beat me, whip me, send me to Detroit, but don't make me write tests!

あーーーーー!!!! テストは嫌! 何をおいてもテストは嫌! ぶっても、むち打っても、デトロイトに送ってもいいけど、テストを書かせないで!

*sob*

*しくしく*

Besides, I don't know how to write the damned things.

おまけに、そんな忌まわしいものの書き方など知りません。

Is this you? Is writing tests right up there with writing documentation and having your fingernails pulled out? Did you open up a test and read

あなたはこんな人ですか? テストを書くことは、ちょうど、ドキュメントを書き、指の爪を引き抜くことですか? テストを開き、読み、

    ######## We start with some black magic
    ######## いくつかの黒魔術を始めます。

and decide that's quite enough for you?

テストはもうたくさんだと判断しますか?

It's ok. That's all gone now. We've done all the black magic for you. And here are the tricks...

いいでしょう。 全ては行ってしまいました。 あなたのために、黒魔術をすべて行いました。 ここにその仕掛けがあります…

テストの基本

Here's the most basic test program.

以下は最も基本的なテストのプログラムです。

    #!/usr/bin/perl -w

    print "1..1\n";

    print 1 + 1 == 2 ? "ok 1\n" : "not ok 1\n";

since 1 + 1 is 2, it prints:

1 + 1 は 2 ですから、次のように表示します:

    1..1
    ok 1

What this says is: 1..1 "I'm going to run one test." [1] ok 1 "The first test passed". And that's about all magic there is to testing. Your basic unit of testing is the ok. For each thing you test, an ok is printed. Simple. Test::Harness interprets your test results to determine if you succeeded or failed (more on that later).

このコードの意味: 1..1[1]「一つのテストを行います。」ok 1 「最初のテストはパスしました。」 そして、これが、テストの魔法のほとんど全部です。 基本的なユニットのテストは ok です。 Test::Harness は、テストの結果を解釈し、成功したか失敗したかを判断します (後では、もっと判断します)。

Writing all these print statements rapidly gets tedious. Fortunately, there's Test::Simple. It has one function, ok().

このような print 文をを全部書くのは、すぐに飽きてしまいます。 幸運なことに、Test::Simple があります。 これには、ok() という一つの関数があります。

    #!/usr/bin/perl -w

    use Test::Simple tests => 1;

    ok( 1 + 1 == 2 );

and that does the same thing as the code above. ok() is the backbone of Perl testing, and we'll be using it instead of roll-your-own from here on. If ok() gets a true value, the test passes. False, it fails.

これは上のコードと同じことをします。 ok() は、Perl のテストの中核です; ここからは、自分で書く代わりに、 ok() を使います。 ok() が真を返せば、テストは合格です。 偽であれば、失敗です。

    #!/usr/bin/perl -w

    use Test::Simple tests => 2;
    ok( 1 + 1 == 2 );
    ok( 2 + 2 == 5 );

from that comes

このコードから、

    1..2
    ok 1
    not ok 2
    #     Failed test (test.pl at line 5)
    # Looks like you failed 1 tests of 2.

1..2 "I'm going to run two tests." This number is used to ensure your test program ran all the way through and didn't die or skip some tests. ok 1 "The first test passed." not ok 2 "The second test failed". Test::Simple helpfully prints out some extra commentary about your tests.

1..2 「二つのテストを行います。」 この番号は、テストプログラムが最初から最後まで実行されたことを保証し、 die したり、いくつかのテストをスキップしたりしていないことも保証します。 ok 1「最初のテストはパスしました。」 not ok 2 「二番目のテストは失敗しました。」 Test::Simple はテストについての有用な特別のコメントを出力します。

It's not scary. Come, hold my hand. We're going to give an example of testing a module. For our example, we'll be testing a date library, Date::ICal. It's on CPAN, so download a copy and follow along. [2]

怖くはありませんよ。 こっちへきて、手を取って。 モジュールをテストする例をみせましょう。 その例に、日付のライブラリである、Date::ICal をテストします。 Date::ICal は、CPANにありますので、コピーをダウンロードして、 進んで下さい [2]。

どこから始めましょう?

This is the hardest part of testing, where do you start? People often get overwhelmed at the apparent enormity of the task of testing a whole module. Best place to start is at the beginning. Date::ICal is an object-oriented module, and that means you start by making an object. So we test new().

ここがテストの一番難しいところです; どこから始めましょう? モジュールの全てをテストすることは、明らかに大きな仕事であり、圧倒されます。 最も良いのは、最初から始めることです。 Date::ICal は、オブジェクト指向のモジュールです; ですから、オブジェクトを 作ることからはじめればいい。 そう、new() をテストしましょう。

    #!/usr/bin/perl -w

    use Test::Simple tests => 2;

    use Date::ICal;

    my $ical = Date::ICal->new;         # create an object
    ok( defined $ical );                # check that we got something
    ok( $ical->isa('Date::ICal') );     # and it's the right class

run that and you should get:

これを実行すると、以下のようになります:

    1..2
    ok 1
    ok 2

congratulations, you've written your first useful test.

おめでとう、最初の有益なテストが書けました。

名前

That output isn't terribly descriptive, is it? When you have two tests you can figure out which one is #2, but what if you have 102?

この出力は、全然記述的じゃないですね? 二つしかテストが無いなら、そのうちの一つが 2 番目のものだと分かりますが、 102 もテストがあったら、どうでしょう?

Each test can be given a little descriptive name as the second argument to ok().

それぞれのテストには、ちょっとした記述的な名前を 2 番目の引数として、 ok() に与えることが出来ます。

    use Test::Simple tests => 2;

    ok( defined $ical,              'new() returned something' );
    ok( $ical->isa('Date::ICal'),   "  and it's the right class" );

So now you'd see...

今度は次のようになります...

    1..2
    ok 1 - new() returned something
    ok 2 -   and it's the right class

マニュアルのテスト

Simplest way to build up a decent testing suite is to just test what the manual says it does. [3] Let's pull something out of the "SYNOPSIS" in Date::ICal and test that all its bits work.

もっとも簡単にきちんとしたテストを作る方法は、ただマニュアルに 書かれていることをテストします[3]。 "SYNOPSIS" in Date::ICal から何かを引いてきて、それを全てテストしましょう。 ちょっとしたことです。

    #!/usr/bin/perl -w

    use Test::Simple tests => 8;

    use Date::ICal;

    $ical = Date::ICal->new( year => 1964, month => 10, day => 16, 
                             hour => 16, min => 12, sec => 47, 
                             tz => '0530' );

    ok( defined $ical,            'new() returned something' );
    ok( $ical->isa('Date::ICal'), "  and it's the right class" );
    ok( $ical->sec   == 47,       '  sec()'   );
    ok( $ical->min   == 12,       '  min()'   );    
    ok( $ical->hour  == 16,       '  hour()'  );
    ok( $ical->day   == 17,       '  day()'   );
    ok( $ical->month == 10,       '  month()' );
    ok( $ical->year  == 1964,     '  year()'  );

run that and you get:

実行すると、次のようになります:

    1..8
    ok 1 - new() returned something
    ok 2 -   and it's the right class
    ok 3 -   sec()
    ok 4 -   min()
    ok 5 -   hour()
    not ok 6 -   day()
    #     Failed test (- at line 16)
    ok 7 -   month()
    ok 8 -   year()
    # Looks like you failed 1 tests of 8.

Whoops, a failure! [4] Test::Simple helpfully lets us know on what line the failure occurred, but not much else. We were supposed to get 17, but we didn't. What did we get?? Dunno. We'll have to re-run the test in the debugger or throw in some print statements to find out.

おぉー、失敗![4] Test::Simpleは、役に立つことに、何行目で失敗したのかを知らせてくれます。 けれど、他には何も知らせません。 17 を得なければならなかったのですが、そうはなりませんでした。 何を得たのでしょうか?? わかりません。 それを見つけるには、デバッガでテストを再実行するか、print 文に 投げるかしなければなりません。

Instead, we'll switch from Test::Simple to Test::More. Test::More does everything Test::Simple does, and more! In fact, Test::More does things exactly the way Test::Simple does. You can literally swap Test::Simple out and put Test::More in its place. That's just what we're going to do.

その代わりに、Test::Simple から、Test::More に切り替えましょう。 Test::More は、Test::Simple の行う全てのことを行えるし、もっと行えます! 実際、Test::More は、Test::Simple が行うことを 正確に 行います。 文字通り、Test::Simple を取り外し、Test::More をそこに置くことが出来ます。 ちょうど、やろうとしていることです。

Test::More does more than Test::Simple. The most important difference at this point is it provides more informative ways to say "ok". Although you can write almost any test with a generic ok(), it can't tell you what went wrong. Instead, we'll use the is() function, which lets us declare that something is supposed to be the same as something else:

Test::More は、Test::Simple より多くのことを行います。 最も重要な違いは、Test::More はより有益な方法で「ok」と言う点です。 一般的な ok() でほとんどすべてのテストを書くことが出来ますが、 ok() では、何が間違っているのかわかりません。 代わりに、is() 関数を使いましょう; is() は、あるものが他のものと 同じであると想定しているということを宣言します:

    #!/usr/bin/perl -w

    use Test::More tests => 8;

    use Date::ICal;

    $ical = Date::ICal->new( year => 1964, month => 10, day => 16, 
                             hour => 16, min => 12, sec => 47, 
                             tz => '0530' );

    ok( defined $ical,            'new() returned something' );
    ok( $ical->isa('Date::ICal'), "  and it's the right class" );
    is( $ical->sec,     47,       '  sec()'   );
    is( $ical->min,     12,       '  min()'   );    
    is( $ical->hour,    16,       '  hour()'  );
    is( $ical->day,     17,       '  day()'   );
    is( $ical->month,   10,       '  month()' );
    is( $ical->year,    1964,     '  year()'  );

"Is $ical->sec 47?" "Is $ical->min 12?" With is() in place, you get some more information

"Is $ical->sec 47?" "Is $ical->min 12?" is() を使うことで、さらに多くの情報を得ることができます

    1..8
    ok 1 - new() returned something
    ok 2 -   and it's the right class
    ok 3 -   sec()
    ok 4 -   min()
    ok 5 -   hour()
    not ok 6 -   day()
    #     Failed test (- at line 16)
    #          got: '16'
    #     expected: '17'
    ok 7 -   month()
    ok 8 -   year()
    # Looks like you failed 1 tests of 8.

letting us know that $ical->day returned 16, but we expected 17. A quick check shows that the code is working fine, we made a mistake when writing up the tests. Just change it to:

$ical->day は、16 を返しましたが、期待していたのは、17 であったと 知らせます。 素早いチェックにより、このコードは正しく動いており、テストを書き上げたときに ミスをしたことを示しています。 そこを変えるだけです:

    is( $ical->day,     16,       '  day()'   );

and everything works.

これで、全部動きます。

So any time you're doing a "this equals that" sort of test, use is(). It even works on arrays. The test is always in scalar context, so you can test how many elements are in a list this way. [5]

「これは、あれである」と言った種類のテストをするときはいつも、is を 使うといいです。 is は、配列でも働きます。 テストは常にスカラコンテキストで動くので、次の方法で、リストの中の 要素がいくつあるかをテストできます。[5]

    is( @foo, 5, 'foo has 5 elements' );

テストは間違っている時もある

Which brings us to a very important lesson. Code has bugs. Tests are code. Ergo, tests have bugs. A failing test could mean a bug in the code, but don't discount the possibility that the test is wrong.

間違いは、とても大切なレッスンになります。 コードにはバグがある。 テストはコードである。 ゆえに、テストにはバグがある。 失敗したテストは、コードにバグがあることを意味します; しかし、テストが 間違っている可能性を排除してはなりません。

On the flip side, don't be tempted to prematurely declare a test incorrect just because you're having trouble finding the bug. Invalidating a test isn't something to be taken lightly, and don't use it as a cop out to avoid work.

反面、時期尚早に、ただ、バグを見つけるのに苦労しているからといって、 テストが不正確であると断言しようという誘惑にかられないように。 テストを無効にすることは、安易にとれるものではありませんし、作業から逃れて、 避けるために、テストを無効にしてはいけません。

たくさんの値のテスト

We're going to be wanting to test a lot of dates here, trying to trick the code with lots of different edge cases. Does it work before 1970? After 2038? Before 1904? Do years after 10,000 give it trouble? Does it get leap years right? We could keep repeating the code above, or we could set up a little try/expect loop.

多くの違ったエッジケースでコードをテストしようとするとき、多くの値を テストしたいと思います。 1970 年以前では、動くだろうか? 2038 年の後は? 1904 年以前は? 10,000 年後に、トラブルが起きるか? 閏年を正しく得られるか? 前述のコードを上のコードを繰り返し続けることもできますし、簡単な try/expect ループを設定することもできます。

    use Test::More tests => 32;
    use Date::ICal;

    my %ICal_Dates = (
            # An ICal string     And the year, month, day
            #                    hour, minute and second we expect.
            '19971024T120000' =>    # from the docs.
                                [ 1997, 10, 24, 12,  0,  0 ],
            '20390123T232832' =>    # after the Unix epoch
                                [ 2039,  1, 23, 23, 28, 32 ],
            '19671225T000000' =>    # before the Unix epoch
                                [ 1967, 12, 25,  0,  0,  0 ],
            '18990505T232323' =>    # before the MacOS epoch
                                [ 1899,  5,  5, 23, 23, 23 ],
    );


    while( my($ical_str, $expect) = each %ICal_Dates ) {
        my $ical = Date::ICal->new( ical => $ical_str );

        ok( defined $ical,            "new(ical => '$ical_str')" );
        ok( $ical->isa('Date::ICal'), "  and it's the right class" );

        is( $ical->year,    $expect->[0],     '  year()'  );
        is( $ical->month,   $expect->[1],     '  month()' );
        is( $ical->day,     $expect->[2],     '  day()'   );
        is( $ical->hour,    $expect->[3],     '  hour()'  );
        is( $ical->min,     $expect->[4],     '  min()'   );    
        is( $ical->sec,     $expect->[5],     '  sec()'   );
    }

So now we can test bunches of dates by just adding them to %ICal_Dates. Now that it's less work to test with more dates, you'll be inclined to just throw more in as you think of them. Only problem is, every time we add to that we have to keep adjusting the use Test::More tests => ## line. That can rapidly get annoying. There's two ways to make this work better.

これで、ただ、%ICal_Dates に日付の束を加えるだけで、テストできます。 さて、たくさんの日付をテストする作業が少なくなったので、 ただ、日付を投げるだけにしたいかもしれません。 唯一の問題は、毎回、use Test::More tests => ## の行を、 調節しなければならない事です。 このことは、急速に煩雑になるでしょう。 二つの方法で、もっとうまくやれます。

First, we can calculate the plan dynamically using the plan() function.

一つめの方法は、plan() 関数を動的に使って、計画を計算します。

    use Test::More;
    use Date::ICal;

    my %ICal_Dates = (
        ...same as before...
    );

    # For each key in the hash we're running 8 tests.
    plan tests => keys(%ICal_Dates) * 8;

    ...and then your tests...

Or to be even more flexible, we use no_plan. This means we're just running some tests, don't know how many. [6]

もしくは、より柔軟に、no_plan を使います。 これにより、いくつあるかを知らないテストをただ走らせます。[6]

    use Test::More 'no_plan';   # instead of tests => 32

now we can just add tests and not have to do all sorts of math to figure out how many we're running.

これで、ただ単にテストを加えるだけで、全てのテストがいくつかあるか 数えなくても、いくつでも、テストできます。

有益な名前

Take a look at this line here

次の行をみてください

    ok( defined $ical,            "new(ical => '$ical_str')" );

we've added more detail about what we're testing and the ICal string itself we're trying out to the name. So you get results like:

テストしていることと、テストしている ICal ストリング自身の詳細を、名前に 加えます。 次のような結果が出ます:

    ok 25 - new(ical => '19971024T120000')
    ok 26 -   and it's the right class
    ok 27 -   year()
    ok 28 -   month()
    ok 29 -   day()
    ok 30 -   hour()
    ok 31 -   min()
    ok 32 -   sec()

if something in there fails, you'll know which one it was and that will make tracking down the problem easier. So try to put a bit of debugging information into the test names.

失敗の中に何かあるなら、それが一つであり、それによって、問題を追跡するのが 簡単になることがわかるでしょう。 ですから、ちょっとしたデバッグ情報をテストの名前に入れてみて下さい。

Describe what the tests test, to make debugging a failed test easier for you or for the next person who runs your test.

そのテストが何をテストするかを記述しておけば、 失敗したテストをデバッグする際、自分や他の人がテストを実行するのが、簡単に なります。

テストをスキップする

Poking around in the existing Date::ICal tests, I found this in t/01sanity.t [7]

Date::ICal で用意されているテストを探し回って、t/01sanity.t に、次のものを 見つけました [7]。

    #!/usr/bin/perl -w

    use Test::More tests => 7;
    use Date::ICal;

    # Make sure epoch time is being handled sanely.
    my $t1 = Date::ICal->new( epoch => 0 );
    is( $t1->epoch, 0,          "Epoch time of 0" );

    # XXX This will only work on unix systems.
    is( $t1->ical, '19700101Z', "  epoch to ical" );

    is( $t1->year,  1970,       "  year()"  );
    is( $t1->month, 1,          "  month()" );
    is( $t1->day,   1,          "  day()"   );

    # like the tests above, but starting with ical instead of epoch
    my $t2 = Date::ICal->new( ical => '19700101Z' );
    is( $t2->ical, '19700101Z', "Start of epoch in ICal notation" );

    is( $t2->epoch, 0,          "  and back to ICal" );

The beginning of the epoch is different on most non-Unix operating systems [8]. Even though Perl smooths out the differences for the most part, certain ports do it differently. MacPerl is one off the top of my head. [9] So rather than just putting a comment in the test, we can explicitly say it's never going to work and skip the test.

たいていの非 UNIX OS では、エポックの始まりが異なっています [8]。 ほとんどの部分で Perl は、差異をならしていますが、ある部分では、違ったように 行います。 今、正確には思い出せませんが、MacPerl はその一つだと思います[9]。 なので、ただテストにコメントをおくだけではなく、はっきりと、決して 働かないように言い、テストをスキップすることが出来ます。

    use Test::More tests => 7;
    use Date::ICal;

    # Make sure epoch time is being handled sanely.
    my $t1 = Date::ICal->new( epoch => 0 );
    is( $t1->epoch, 0,          "Epoch time of 0" );

    SKIP: {
        skip('epoch to ICal not working on MacOS', 6) 
            if $^O eq 'MacOS';

        is( $t1->ical, '19700101Z', "  epoch to ical" );

        is( $t1->year,  1970,       "  year()"  );
        is( $t1->month, 1,          "  month()" );
        is( $t1->day,   1,          "  day()"   );

        # like the tests above, but starting with ical instead of epoch
        my $t2 = Date::ICal->new( ical => '19700101Z' );
        is( $t2->ical, '19700101Z', "Start of epoch in ICal notation" );

        is( $t2->epoch, 0,          "  and back to ICal" );
    }

A little bit of magic happens here. When running on anything but MacOS, all the tests run normally. But when on MacOS, skip() causes the entire contents of the SKIP block to be jumped over. It's never run. Instead, it prints special output that tells Test::Harness that the tests have been skipped.

ここで、ちょっとした魔法が起きます。 MacOS 以外で動いた場合、全てのテストは普通にテストされます。 しかし、MacOS 上の場合、skip() によって、SKIP ブロックの中の全ての内容が 飛ばされます。 決して動くことはありません。 かわりに、テストがスキップされていることを Test::Harness に伝える特別な 出力がプリントされます。

    1..7
    ok 1 - Epoch time of 0
    ok 2 # skip epoch to ICal not working on MacOS
    ok 3 # skip epoch to ICal not working on MacOS
    ok 4 # skip epoch to ICal not working on MacOS
    ok 5 # skip epoch to ICal not working on MacOS
    ok 6 # skip epoch to ICal not working on MacOS
    ok 7 # skip epoch to ICal not working on MacOS

This means your tests won't fail on MacOS. This means less emails from MacPerl users telling you about failing tests that you know will never work. You've got to be careful with skip tests. These are for tests which don't work and never will. It is not for skipping genuine bugs (we'll get to that in a moment).

これは、MacOS 上で、テストは失敗しないという意味です。 これで、MacPerl のユーザーからの、動かないと分かっているテストが動かないと 報告する email が少なくなります。 テストのスキップについて慎重になるように。スキップのテストは、動かない、 決して動かない テストに対してあるものです。 本物のバグをスキップする為のものではありません(すぐにそうなるでしょう)。

The tests are wholly and completely skipped. [10] This will work.

このテストは、まったく、完全にスキップされます [10]。 以下のコードは、動きます。

    SKIP: {
        skip("I don't wanna die!");

        die, die, die, die, die;
    }

ToDo テスト

Thumbing through the Date::ICal man page, I came across this:

Date::ICal の man ページをざっと目を通していて、次のものに遭遇しました:

   ical

       $ical_string = $ical->ical;
   Retrieves, or sets, the date on the object, using any
   valid ICal date/time string.
   オブジェクトの日付の取得、または、セット。
   すべての妥当な ICal date/time 文字列を使って、オブジェクトに日付をセットする。

"Retrieves or sets". Hmmm, didn't see a test for using ical() to set the date in the Date::ICal test suite. So I'll write one.

「取得またはセット」。 ふむ、Date::ICal のテストで、日付をセットする ical() を使うテストを 見ませんでした。 私は、次のように書くでしょう。

    use Test::More tests => 1;
    use Date::ICal;

    my $ical = Date::ICal->new;
    $ical->ical('20201231Z');
    is( $ical->ical, '20201231Z',   'Setting via ical()' );

run that and I get

これを実行すると、

    1..1
    not ok 1 - Setting via ical()
    #     Failed test (- at line 6)
    #          got: '20010814T233649Z'
    #     expected: '20201231Z'
    # Looks like you failed 1 tests of 1.

Whoops! Looks like it's unimplemented. Let's assume we don't have the time to fix this. [11] Normally, you'd just comment out the test and put a note in a todo list somewhere. Instead, we're going to explicitly state "this test will fail" by wrapping it in a TODO block.

おぉー! 実行されないようだ。さて、これを修正する時間がないと想定しましょう。[11] ふつうは、このテストをコメントにして、ToDo リストに書き留めておくでしょう。 その代わりに、TODOブロック内でラッピングして(包んで)、「このテストが 失敗した」という明らかな状態にしましょう。

    use Test::More tests => 1;

    TODO: {
        local $TODO = 'ical($ical) not yet implemented';

        my $ical = Date::ICal->new;
        $ical->ical('20201231Z');

        is( $ical->ical, '20201231Z',   'Setting via ical()' );
    }

Now when you run, it's a little different:

実行すると、ちょっとした違いがあります:

    1..1
    not ok 1 - Setting via ical() # TODO ical($ical) not yet implemented
    #          got: '20010822T201551Z'
    #     expected: '20201231Z'

Test::More doesn't say "Looks like you failed 1 tests of 1". That '# TODO' tells Test::Harness "this is supposed to fail" and it treats a failure as a successful test. So you can write tests even before you've fixed the underlying code.

Test::Moreは、「一つのテストの中の一つが失敗したようだ」とは言いません。 この「# TODO」は、Test::Harness に「これは、失敗すると思われる」と伝え、 Test::Harness は、失敗したテストを成功したテストのように扱います。 これで、バグを修正する前にテストを書くことができます。

If a TODO test passes, Test::Harness will report it "UNEXPECTEDLY SUCCEEDED". When that happens, you simply remove the TODO block with local $TODO and turn it into a real test.

もし、TODO テストがパスすると、Test::Harness は、テストが、「思いがけず 成功した」と報告します。 これが起きれば、local $TODO で TODO ブロックを外して、本当のテストに 変えれば良いでしょう。

汚染モードでのテスト

Taint mode is a funny thing. It's the globalest of all global features. Once you turn it on, it affects all code in your program and all modules used (and all the modules they use). If a single piece of code isn't taint clean, the whole thing explodes. With that in mind, it's very important to ensure your module works under taint mode.

汚染モードは楽しいものです。 全ての全体的な特徴のなかでも、もっとも全体的なものです。 汚染モードを付けると、汚染モードは、プログラムの全てのコードと 全ての モジュール(と、それらが使っている全てのモジュール)に影響します。 コードの一つでも、汚染されていれば、全てが爆発します。 このことを念頭に置いて、汚染モードの下で、モジュールが動くのを保証することは、 とても重要です。

It's very simple to have your tests run under taint mode. Just throw a -T into the #! line. Test::Harness will read the switches in #! and use them to run your tests.

テストを、汚染モードで走らせるのは、とても簡単です。 #! 行に、-T を投げるだけです。 Test::Harness は、#! 行のスイッチを読み、テストでそのスイッチを使います。

    #!/usr/bin/perl -Tw

    ...test normally here...

So when you say make test it will be run with taint mode and warnings on.

で、make test をすると、テストは汚染モードと警告を有効にして走るでしょう。

脚注

  1. The first number doesn't really mean anything, but it has to be 1. It's the second number that's important.

    最初の数字は実際何も意味していませんが、1 でなければいけません。 重要なのは、二番目の数字です。

  2. For those following along at home, I'm using version 1.31. It has some bugs, which is good -- we'll uncover them with our tests.

    以下に進むため、バージョン1.31を使います。 このバージョンには、バグが少々ありますが、 大丈夫です -- テストでバグを明らかにしましょう。

  3. You can actually take this one step further and test the manual itself. Have a look at Test::Inline (formerly Pod::Tests).

    実際に、このステップをもっと取り入れ、マニュアル自身をテストできます。 Test::Inlineを見なさい。 (以前の Pod::Tests)

  4. Yes, there's a mistake in the test suite. What! Me, contrived?

    このテストには、間違いがあります。 何! 私が、仕組んだって?

  5. We'll get to testing the contents of lists later.

    後で、リストの内容をテストします。

  6. But what happens if your test program dies halfway through?! Since we didn't say how many tests we're going to run, how can we know it failed? No problem, Test::More employs some magic to catch that death and turn the test into a failure, even if every test passed up to that point.

    しかし、テストプログラムが途中で死んだら、何が起きるのだろうか?! どれくらいのテストを動かしているのか書かないで、どうやって 失敗したのかわかるだろうか? 問題ありません。 Test::More は、いくつかの魔法を使い、その死を捕らえ、テストを失敗に変えます。 たとえ、全てのテストが、その場所で合格したとしても。

  7. I cleaned it up a little.

    ちょっとだけ綺麗にしました。

  8. Most Operating Systems record time as the number of seconds since a certain date. This date is the beginning of the epoch. Unix's starts at midnight January 1st, 1970 GMT.

    たいていの OS は、ある日付からの秒数として時間を記録します。 この日付が、エポックの始まりです。 UNIX のエポックの始まりは、標準時の 1970 年の 1 月 1 日の深夜です。

  9. MacOS's epoch is midnight January 1st, 1904. VMS's is midnight, November 17th, 1858, but vmsperl emulates the Unix epoch so it's not a problem.

    MacOS のエポックは、1904 年の 1 月 1 日の深夜です。 VMS のエポックは、1858 年の11 月 17 日の深夜です。 ですが、vmsperl は、UNIX のエポックをエミュレートしているので、問題は ありません。

  10. As long as the code inside the SKIP block at least compiles. Please don't ask how. No, it's not a filter.

    SKIP ブロックの中にコードが在る限り、少なくともコンパイルされます。 どうやってるかは聞かないで下さい。 フィルターではありません。

  11. Do NOT be tempted to use TODO tests as a way to avoid fixing simple bugs!

    簡単なバグを直すのを避けるための方法として、TODO テストを 使おうとしてはいけません!

作者

Michael G Schwern <schwern@pobox.com> and the perl-qa dancers!

コピーライト

Copyright 2001 by Michael G Schwern <schwern@pobox.com>.

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

Irrespective of its distribution, all code examples in these files are hereby placed into the public domain. You are permitted and encouraged to use this code in your own programs for fun or for profit as you see fit. A simple comment in the code giving credit would be courteous but is not required.