テストファーストの弊害
テストファーストは、XP（エクストリームプログラミング）の中でも特に広く浸透したプラクティスの１つである。 テストファーストは、モノを作るよりも前に、まずテストから着手する、という手法だ。モノが無ければテストできないという常識を、根本からひっくり返す斬新なアイディアは、多くのソフトウェア開発者に衝撃を与えた。 テストファーストは、短期開発におけるXPの有効性が認められ、JUnitなどのテストツールが普及した今では、広く受け入れられるようになった。 だが、このようなまったく新しい手法は、初めはなかなか受け入れられ難いが、いったん受け入れられると、今度は逆に、魔法の技術であるかのように盲信されやすい。テストファーストについても、最近では「JUnitでテストコードを書いていれば、ソフトウェアの品質は問題ない」という風潮が広まりつつあるような危惧も感じる。 テストファーストの効果は、多くの人が認め
Test::More
NAME Test::More - yet another framework for writing test scripts SYNOPSIS use Test::More tests => 23; # or use Test::More skip_all => $reason; # or use Test::More; # see done_testing() require_ok( 'Some::Module' ); # Various ways to say "ok" ok($got eq $expected, $test_name); is ($got, $expected, $test_name); isnt($got, $expected, $test_name); # Rather than print STDERR "# here's what went wrong\n
Test::Harness
NAME Test::Harness - Run Perl standard test scripts with statistics VERSION Version 3.48 SYNOPSIS use Test::Harness; runtests(@test_files); DESCRIPTION Although, for historical reasons, the Test::Harness distribution takes its name from this module it now exists only to provide TAP::Harness with an interface that is somewhat backwards compatible with Test::Harness 2.xx. If you're writing new code
はじめてのTest::More
Chapter1の後半戦は、Test::More。 Perl Testing: A Developer's Notebook (Developers Notebook) Test::MoreはTest::Simpleのスーパーセットで完全に置き換えて使ってOK、モジュールをただしく読み込めたかどうかなどのテスト関数も含めいろんな機能あるでよ、とのことです。 早速。 package AnalyzeSentence; use strict; use warnings; use base qw/Exporter/; our $WORD_SEPARATOR = qr/\s+/; our @EXPORT_OK = qw($WORD_SEPARATOR count_words words); sub words { my $sentence = shift; return split $WORD_SE
Test::More - 自動テストのためのテストプログラムを書く - Perl入門ゼミ
Perl › 試験 CPANにあるPerlモジュールのほぼすべてには、プログラムを試験するためのプログラムが、添付されています。プログラムだけではなくって、プログラムを試験するためのプログラムも一緒についてくるんです。これを、自動試験と呼びます。プログラムをひとつひとつ手で実行しなくても、自動試験のプログラムを実行するだけで、プログラムが正しく動くかどうかを確認できます。 Perlでは、標準モジュールであるTest::Moreを使って自動試験のプログラムを書くのが便利です。ここでは、自動試験の利点と、Test::Moreによる自動試験の記述方法を解説します。 自動試験の利点 1.リグレッションテストが簡単にできる。 リグレッションテストは、退行試験とも呼ばれ、プログラムに機能を追加したときに元の機能が正しく動くことを確認する試験のことです。自動試験を作成しておけば、プログラムに機能を追加し
Test::Tutorial - ごく基本的なテストを書くことについてのチュートリアル - perldoc.jp
名前¶ Test::Tutorial - ごく基本的なテストを書くことについてのチュートリアル 概要¶ あーーーーー!!!!テストは嫌! 何をおいてもテストは嫌! ぶっても、むち打っても、デトロイトに送ってもいいけど、 テストを書かせないで! *しくしく* おまけに、そんな忌まわしいものの書き方など知りません。 あなたはこんな人ですか？ テストを書くことは、ちょうど、ドキュメントを書き、指の爪を引き抜くことですか？ テストを開き、読み、 ######## いくつかの黒魔術を始めます。 テストはもうたくさんだと判断しますか？ いいでしょう。全ては行ってしまいました。あなたのために、黒魔術をすべて行いました ここにその仕掛けがあります… テストの基本¶ 最も基本的なテストのプログラム。 #!/usr/bin/perl -w print "1..1\n"; print 1 + 1 == 2 ?
第30回 Test::Class：ユニットテストに使うだけでなく | gihyo.jp
メタデータからテスト件数を取得する 前回はテストファイルやテストデータの数からテストプランを計算するモジュールを紹介しました。今回はその続きとして、テストファイルのメタデータからテストの数を求めるモジュールを紹介していきましょう。これらのモジュールの多くは1994年にケント・ベック（Kent Beck）氏がSmalltalk向けに書いたSUnitを祖先にもつ、いわゆるxUnit系のフレームワークに属するものですが、Perlにはそれ以前からTest Anything Protocolを使った独自のテスト手法が存在していたため、Javaなどで使われている同種のフレームワークとはやや毛色の違う部分もあります。一般的にはクラスをひとつ書くたびに対応するユニットテスト用のクラスを書くのがよいように言われていますが、ここではもっとゆるく、テストを自動的に検出してくれるだけでなく、テストの事前事後になん
第29回 Test::Base：データ本位のテストをするときは | gihyo.jp
テストは実行する前にも数えられるはず 前回、前々回と見てきたように、Test Anything Protocolでは本来ひとつひとつのテストに連番が割り振られます。新しいテストを追加したければ、テストファイルの末尾に移動して、テスト番号をひとつずつ増やしながらテストを書き進め、終わったら先頭に戻って宣言部を更新する。先頭に戻るのが面倒であれば宣言部を末尾に移してもよいですが、いずれにしてもテストを追加し終わった時点でテストの件数はわかっているのですから、更新に困ることはないはずでした。 ところが、Perl 5の時代に入ってテスト用のモジュールが連番を振ってくれるようになった結果、テストの件数がわかりづらくなったため、no_planやdone_testingのように実際にテストを実行した回数をテストの総数とみなす手法が登場した――というのが前回の話でしたが、そういった妥協案は、Test An
第28回 Test::More：no_planからdone_testingへ | gihyo.jp
計画的に実行するのはよいことですが 前回も紹介したように、Test Anything Protocolでは「これから10個のテストを実行します」と宣言する場合はこのように書くことになっていました。 use strict; print "1..10\n"; # 宣言部 for (1..10) { print "ok $_\n"; } このような宣言部の存在は、テスト結果をパースして分析するTest::Harnessのようなツールにとっては非常に便利なものですが、たとえば環境によってテストの数がかわるとき、あるいはテストファイルが非常に長くなってきたとき、はたまた多くの人が平行してファイルやテストの追加作業をしているため最後にマージするまでテストの数がわからないとき、事前にテストの数を把握していなければならないというのは、大きな制約にもなりえます。 単純そうに見えるTest Anything
第27回 Test::Most：Test::Moreでは物足りなくなってきたら | gihyo.jp
Test Anything Protocol Perlは非常にテストを重視している言語です。連載第14回ではPerl本体のテスト数がどのように推移してきたかを、また連載第24回ではCPANモジュールの品質保証に大きな役割を果たしてきたCPANTSについて簡単に紹介しましたが、Perlとテストのつながりはそれだけではありません。CPANにはTestを名前に含むディストリビューションが500以上もあがっていますし（これは全ディストリビューション数の約2.5％にあたります）、Perlで標準的に使われているテスト形式はTest Anything Protocol (TAP)という名前を得て多くの言語に移植され、2008年からはIETFの標準化を目指した活動も始まっています――というと何やらすごいプロトコルのように聞こえるかもしれませんが、Test Anything Protocolというのは要
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Amazon.co.jp: Perl Testing: A Developer's Notebook: Langworth, Ian, Chromatic: 本