貴方がまだ使っていないだろうTest::Moreの5つの特色 | taro-nishinoの日記 | スラド
以前にも書きましたが、私もCPAN Testersの下辺の最下位に参加しています。いろいろなテストの中身を覗くと、まだ新しいTest::Moreの特色がすべて使われているとは言えないと感じました。 Test::Moreを使うのはCPAN作者のみならず、Perlerなら必須の道具です。ですから、最低常識に位置します。そういう時に、David Golden氏は御自分も失念していたかのようにとぼけて、エッセイという形を取りながらも、こじんまりと綺麗に新しいTest::Moreの特色を"Five Test::More features you might not be using yet"で説明してくれています。 私は以前にも書いたことがありましたが、Perl本体やCPANモジュールのドキュメントやハウツーものは一切訳さないと公言しました。その理由は訳さなければならないほどの英語ではない(せいぜい
Test::Unit に Test::Tap を被せてみました - Tociyuki::Diary
Ruby の添付ライブラリ test/unit は、Java のテスト・フレームワークを範にしているようで、煩雑で軽やかさがないのが難点です。なぜ、Perl のテスト・フレームワークに倣わなかったのか、Ruby の不思議の一つだと思っています。id:dankogai さんが不満を述べるのも、わかる気がします。 ⇒ 404 Blog Not Found:Ruby beyond Rails - 書評 - まるごとRuby! RubyはPerlに比べて、余計なところでTMTOWTDIを発揮しているように思えてならない。それを一番強く感じるのがテストのフレームワークで、なんであんなに種類があるのかわからない。TAPでほぼ統一されているPerlの連帯感からすると、テスト一個のためにクラスを書かせるなんて、間違った傲慢(false form of hubris)にしか感じられないのだが。 もっとも、賢
第1回 Perlにおけるテストの概要／TAPとは？ | gihyo.jp
モバイルファクトリーの松野です。 今回から数回にわたって、Perl におけるテスト手法についてリレー形式で詳細に解説していきたいとおもいます。 今回は初回ですので、ざっくりと概論になります。 Perlの世界におけるテストの重要性 Perlの世界においてはテスト（test）は大変重要視されています。 その特徴がよく表れているのがCPAN Testersではないでしょうか。 CPAN Testers Perlといえば何はなくともCPANなわけですが、CPANでモジュールを探していると、図1のように、「CPAN Testers」という項目があることに気付きます。 図1 CPAN Testers 世界中のPerl Mongersが、自分のマシンでテストを動かして、その結果をCPANに送っているのです。これにより、様々なOS／CPU／versionのPerlでテストがされています。貴方も気軽にCP
TAPの話 - Unknown::Programming
http://d.hatena.ne.jp/tokuhirom/20080305/1204677112 404 Blog Not Found:「同じコード」の同じって何さ - TAPのススメ 弾さんの記事見て思い出した。 以前、id:tokuhiromさんに教えてもらったTAPの話ですが、折角なので導入しよーかと。 PHP版HTML_FillInFormのテストをTAP形式に。ってかもともと出力はTAP形式になってたので、今回の変更点としては、 #!php <?php error_reporting( E_ALL ); require_once 'Test.class.php'; plan(1); require_ok('HTML/FillInForm.class.php'); こんな感じで一行目に#!にphpを指定しとけばOK。 これでPerlのproveコマンドが使えるお！素晴らしい！
「同じコード」の同じって何さ - TAPのススメ : 404 Blog Not Found
2008年03月27日03:00 カテゴリArtLightweight Languages 「同じコード」の同じって何さ - TAPのススメ 問題は、この「同じコード」の定義。 「誰が書いても同じコード」は大事なことなのか - ひがやすを blog でも、「誰が書いても同じコード」にするってのは、そもそも無理だと思うんだよね。そうやって、わざわざドキュメントをたくさん書かせても、めためたなコードを書くやつはいて、総合テストするときに、現場は燃え上がるもの。ある程度の規模以上のプロジェクトなら、どこでもそんな感じじゃないかと思います。同じ「書き方」をしなければならないのか? 結果が「同じ」ならいいのか? もし後者だとしたら、実は 重要なのは、「誰でもメンテナンスできるコード」にすること。そのために、コーディング規約は、きちんと決めてみんなで守る、それ以上は、がちがちに縛る必要はない。 すら必
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
【TAS】コーディでアーケードーモードを魅せプレイでクリア【SFZ3】
