Test-Simple-0.98 > Test::Tutorial
Test-Simple-0.98
CPANで確認する
Other versions:
Test-Simple-0.99
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";

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 です。 テストをする毎に、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 をテストします。 これは 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

「$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.

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 を 使いましょう。 これは、配列でも働きます。 テストは常にスカラコンテキストで動くので、次の方法で、リストの中の 要素がいくつあるかをテストできます。[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 番目の数字です。

  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.

    しかし、テストプログラムが途中で die しだら、何が起きるのでしょう?! どれくらいのテストを動かしているのか書かないで、どうやって 失敗したのかわかるのでしょう? 問題ありません。 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.

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