Test-Simple-0.99 > Test::Tutorial
Test-Simple-0.99
CPANで確認する
Other versions:
Test-Simple-0.98
Test-Simple-0.96
Test-Simple-0.94
Test-Simple-0.47
Source
編集

名前

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";

Because 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().

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

    #!/usr/bin/perl -w
    
    use Test::Simple tests => 1;
    
    ok( 1 + 1 == 2 );

That does the same thing as the previous code. 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 a plan. It helps 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 「二つのテストを行います」。 この番号は、テストプログラムが最初から最後まで実行されたことを保証し、 死んだり、いくつかのテストをスキップしたりしていないことも保証する助けになります。 ok 1「最初のテストはパスしました。」 not ok 2 「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. The best place to start is at the beginning. Date::ICal is an object-oriented module, and that means you start by making an object. Test new().

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

    #!/usr/bin/perl -w
    
    # assume these two lines are in all subsequent examples
    use strict;
    use warnings;
    
    use Test::Simple tests => 2;
    
    use Date::ICal;

    my $ical = Date::ICal->new;         # オブジェクトを作成し
    ok( defined $ical );                # 何かを得たかをテストし
    ok( $ical->isa('Date::ICal') );     # そして、正しいクラスかテストします

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 tests?

この出力は、全然記述的じゃないですね? 2つしかテストが無いなら、そのうちの一つが 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" );

Now you'll see:

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

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

マニュアルのテスト

The 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. You could re-run the test in the debugger or throw in some print statements to find out.

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

Instead, 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. The is() function 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() は、あるものが他のものと同じであると思われると私たちに宣言させます:

    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 more information:

"$ical->sec は 47?" "$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.

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

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

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

... and everything works.

... これで、全部動きます。

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 an array this way. [5]

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

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

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

This brings up 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年後に、トラブルが起きるか? 閏年を正しく得られるか? 上のコードを繰り返し続けるか、ループを試みるかを、期待することが出来ます。

    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()'   );
    }

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 are 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...

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

よりフレキシブルに、done_testing を使いましょう。これにより、 いくつかのテストをただ走らせます。 いくつなのかは知りません[6]。

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

    ... # tests here

    done_testing();   # reached the end safely

If you don't specify a plan, Test::More expects to see done_testing() before your program exits. It will warn you if you forget it. You can give done_testing() an optional number of tests you expected to run, and if the number ran differs, Test::More will give you another kind of warning.

プランを特定しないと、Test::More は、プログラムが終了する前に、 done_testing() があると期待します。もし、書き忘れていれば警告します。 done_testing() に、実行される予定のテストの数を渡すこともできます。 動いた数が違っていれば、Test::More は、別の種類の警告が出ます。

有益な名前

Take a look at the line:

次の行をみてください

    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. 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] Rather than putting a comment in the test and hoping someone will read the test while debugging the failure, 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 Mac OS', 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 never runs. Instead, skip() 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 fewer 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 テスト

While 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. I didn't see a test for using ical() to set the date in the Date::ICal test suite. So I wrote 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. I saw:

これを実行すると:

    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. Assume you 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, 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. 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, 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...

When you say make test it will run with taint mode 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番目の数字です。

  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 <[email protected]> and the perl-qa dancers!

コピーライト

Copyright 2001 by Michael G Schwern <[email protected]>.

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.

Powered by Amon2, 翻訳, サイト. Operated by Japan Perl Association