ドキュメントとテストコードつきのPerlスクリプトを書く方法 - kazuhoのメモ置き場
Re http://d.hatena.ne.jp/perlcodesample/20091130/1258979624, http://mt.endeworks.jp/d-6/2009/12/scriptsubimport.html スクリプトとコードとテストを単一のファイルにまとめたい*1という需要が、かねて自分の中であったので教えを請うた結果、以下のような感じで書けばいいことがわかった。 #! /usr/bin/perl use modules...; my $global = ...; sub foo { ... } sub bar { ... } run_tests() if $ENV{HARNESS_ACTIVE}; # メインのコード foo(); bar(); ... sub run_tests { ... exit; } __END__ =head1 NAME my_scr
Perl:テストコードの書き方
Perlはテストコードを作成するためのユーティリティも充実しています。 CPAN モジュールの多くはテストコードを備えているので、サンプルにも事欠かないでしょう。 index Perlの代表的なテストモジュール Test::More がもっとも利用されるテストモジュールのように感じますが、それ以外にも便利なモジュールはたくさんありますし、もちろん、下に挙げた以外にも便利なモジュールはあります。 コードのテスト Test::Simple Test::More Test::Base Test::Most Test::Differences Test::Deep Test::Warn Test::Exception Test::Harness Test::Fatal Test::Declare Test::Output Test::LongString Test::BinaryData Test
[perl] コントローラがどのテンプレを表示したかをテストする - tokuhirom's blog
Module::Spy をつかう。 my $render = spy_on('Text::Xslate', 'render'); # コントローラをよぶ ...; my $tmpl = $render->calls_first->[1]; ok { $tmpl eq 'my/index.tt' };
Test::TCPを使ってテスト用にmemcached, app, nginxサーバを立てる - $shibayu36->blog;
テストをするときに、テスト用のみのMySQLとかmemcachedとか、アプリケーションサーバとかを立てたい時がある。MySQLの場合はTest::mysqldを利用すればすぐできるが、それ以外の場合もdaemonの場合はTest::TCPを使ってすぐにテスト用のサーバを立てることができるので、そのメモ。 テスト用memcachedサーバを作る Test::TCPが渡してくれるportを使って起動 Test::TCPが返すオブジェクトがguardのようなオブジェクトになっていて、スコープが切れるとプロセスを勝手に落としてくれる my $memd = Test::TCP->new( code => sub { my $port = shift; exec "memcached -p $port"; }, ); my $client = Cache::Memcached::Fast->new(
LWP::Protocol::PSGIを使ってAPIを叩くメソッドのテストを書く - $shibayu36->blog;
テストをするときに外部のAPIを叩く部分のテストを書きたい場合、出来る限り外部にアクセスせずにテストを書きたい。そういう時 Test::Mock::Guardを使って該当部分のメソッドが特定のデータを返すように書き換えてしまう LWP::Protocol::PSGIを使うなど、APIを叩くclient部分を差し替える Test::TCPを使って、APIのserver部分を差し替える などの方法がある。 今回はLWP::Protocol::PSGIを使ってAPIを叩くclient部分を差し替えるというのをやってみた。 テストしたい実装 例えばはてなブックマーク件数取得APIを使った実装があるとする。 以下の様な感じ。 package Bookmark::Client; use strict; use warnings; use URI; use URI::QueryParam; use LW
テストについての個人の雑感 - tokuhirom's blog
テストについての個人の雑感です。ここでいうテストってのは、なんかいわゆる開発をドライブするための開発者用のテストについてであって、品質の保証とかについては一切かんがえてません。 ざっくりいうと 「テストを書いた方が効率的に開発がすすむ場合にはテストを書く」 テストに対する認識 ソフトウェアにたいするテスト というものはソフトウェアそのものの価値には関係しない。 なので、テストにたいしてかけるコストなど、すくなければすくないほど良いにきまっておる。 Open Source Software のテストについて オープンソースソフトウェアの場合、送られてきた patch の品質を travis ci で確認したい、っていう要件とか、手元の環境以外での動作確認などを行いたいので、それなりにテストを書く必要がある。 まして、僕が OSS として公開しているものはライブラリが多い。ライブラリは一般にテ
Test::Base::SubTest というモジュールを作った。またはテストケースとテストコードは分離されていたほうが嬉しい話 - Cside::Weblog
2014-01-15 Test::Base::SubTest というモジュールを作った。またはテストケースとテストコードは分離されていたほうが嬉しい話 perl 自分は Test::Base が好きでよく使うのだけど、subtest 的な、テストのグルーピングができないのがずっっっと不満だったので、Test::Base::SubTest というモジュールを書いた。 https://metacpan.org/release/CSIDE/Test-Base-SubTest-0.1 https://github.com/Cside/Test-Base-SubTest 以下の様な拡張記法が使えるようになる。### でsubtestの 1 単位を表現する。 use Test::Base::SubTest; filters { input => [qw(eval)] }; run_is input =
Webアプリケーションのテストを書くときに考えていること - 車輪を再発明 / koba04の日記
テストを書く目的 自分の書いたコードが意図した通りに動いてるか確認するために書くのですが、自分が楽をするためと他の人のために書いてます。 自分が楽するため Webアプリの場合、実装した機能がちゃんと動作するかを確認するために何度もブラウザポチポチしてというのは時間がかかります。なのでその回数をなるべく減らすためにテストとして書けるところはなるべくテストで確認して、ブラウザポチポチする回数を必要最低限にしたいと思っています。 ブラウザポチポチするのも立派なテストだと思っています。再現性のない。 他の人のため テストがないと他の人がその機能に関連する機能を変更しようとした時に変更の影響がないのか確認することが出来ず、その機能に対するテストを手動で行わせてしまうことになってしまいます。 テスト書く時間がない問題 テストの話をすると書く時間がないと言われたりしますが、既存の開発の流れにテスト書くこ
スポーツの秋とテスト - ainameの日記
体育の日なので、テストの話を書きます。 テスト書きすぎ問題 - hitode909の日記 階層を増やしすぎるとテストが多くなりがちという問題 - はこべブログ ♨ テストと対応関係 - $shibayu36->blog; 体育の日って高速に唱えるとテストの日に聴こえる - ✘╹◡╹✘ ソフトウェア・テストと安全なソフトウェアを作ることについての思索 - 青き花へ テスト書きすぎ問題についてから始まり、テストの書き方ノウハウってあんまり共有されないよねって話があったので、自分も id:shibayu36 さんの話に乗っかるとする。 以下、テストと対応関係 - $shibayu36->blog;からコードを引用しました。 package Blog; use strict; use warnings; sub new { my ($class, $args) = @_; return bless
Using the Power to Prove
This document discusses using the prove command-line tool to run tests and other scripts. Prove is a test runner that uses the Test Anything Protocol (TAP) to aggregate results. It can run tests and scripts written in any language by specifying the interpreter with --exec. Extensions other than .t can be run by setting --ext. Prove searches for tests in the t/ directory by default but can run any
perl な web application のためのテスト情報 を #yapcasia で話してきました - soh335 memo
yapc::asia 2013 で perl の test 回りの話をしてきました。 去年からテストについて色々取り組んでいた所で、実際どういうモジュールでどうコードを書いてるかっていう説明が出来たと思います。 他の人がどういうテストを書いているかとかも気になるので、なにか気になったりしたら話したりしたいです。 継ぎ足しでスライドを作っていたら、 test::mock::guard のコードの説明がなくなっていて、なくなっていたと思ったら後ろから出てきたり、久しぶりに人前で喋ったせいか、珈琲のストローとマイクを間違えて喋ったりしました。 335さんこういうキャラの人だったのか。— ダメ人間 (@dameninngenn) September 20, 2013 335「びっくりだ！」聴衆（こっちがだ） #yapcasia— ひさいち (@hisaichi5518) September 20,
Perl Beginners #1のビギナーズ・セッションで、Perlのテストについて聞いてみた - hsksnote
Perl Beginners #1 : ATND Perl初心者向けのイベントに行ってきた。ビギナーズ・セッションで発表（質問）してみた。 ビギナーズセッション Perl初心者（でなくても良いですが）に登壇していただいて質問して頂き、それに対して聴衆の方々が回答していく、という形式のセッションとなります。 時間が１５分間割り当てられますので、その範囲内でご自由に質問・発表をしてください。 発表（質問）用のスライドはこちら。はてなってslideshare貼れなかったっけ？ Perlのテストがわからない 話逸れるけど、この勉強会は、発表者（質問者）のスライドはあんまりわかってない状態で書いてるし、その場で答えてもらってるわけだから、スライド自体よりそれに対する答えを含めたレポートっていうのが、他の勉強会より重要になるんじゃないかと思った。 本題に戻る。質問したことに対しての回答を以下に。メモ取
TDD Best Practices in Perl
In this article I've collected the best practices of TDD (Test Driven development) that help me in my work. I brought them together for the future reference, updates, sharing and discussion. Obvious TDD advantages Interface is created "automatically" Only really needable features are implemented System is developed by small steps It forces to write modular code Design errors are recognized on the
Module::Setupで身に付けるよい習慣 - Perl日誌
あらすじ 前回[twitter:@hachiojipm]で行われた[twitter:@norry_gogo]さんのLTで次のような発言がありました。 自分が書いたPerlコードを添削してくれる人が周りにいなくて困ってる 添削したったでー https://github.com/okamuuu/Twitter-Reader おすすめのファイル構成について 一枚岩のスクリプトだとテストがしづらいので普段から以下のようなディレクトリ構成にする事をおすすめします。 Your-Dist/script/*.pl Your-Dist/t/*.t Your-Dist/lib/**/*.pm Your-Dist/Makefile.PLscriptはbinでも何でも良いと思います。こんな感じのディレクトリがいいと思います。 それを簡単につくるためのcpanモジュールがいくつかあるのですが、今回はその中からMod
テスト駆動開発のすすめ - Perl日誌
hachiojipmに行ってきたのですが#4でも#5でもTestを書くのが難しいという声が聞こえたので「テストは書いてみると簡単」「テストがあると開発が楽」という事を伝えてみようと努力する試みです。 ということでサンプルコードを書いてみました。 https://github.com/okamuuu/Sample-Plack-Test 紹介するサンプルコードについて ここで紹介しているスクリプトはある男がBlogを作ろうと思ったがどうせたいしたことしないので俺俺WaFをつくってやろうとして実際にやったテスト駆動開発です。 おもむろにt/web.tとかつくってみる 最初にテストを書いてみましょう。 #!/usr/bin/env perl use strict; use warnings; use Test::Most; use Plack::Test; use HTTP::Request::C
Five Test::More features you might not be using yet
I’ve been using Test::More for so long that I sometimes forget about new features that have been added in the last couple years. If you’re like me and would like a refresher, here’s a list of five useful features that you might want to start using. Unless otherwise noted, you will need at least version 0.88 of Test::More. 1. done_testing instead of no_plan 🔗︎ If you don’t know how many tests you
プロジェクト開発におけるテスト用DBの(使い|作り)方
昔書いたような気がしてたけど書いてなかったので。 モジュールをつくっていてDB回りのテストを書きたい場合は Test::mysqldやTest::postgresql を使うこと。 CPANなんかに上げるモジュールではなく、お仕事プロジェクトのコードを書いていて DB回りのテストを書きたいケースについてです。 私はMySQLを利用しているので、Test::mysqldをつかってもよいのですが、 起動コストがそれなりにかかるのと、ローカルの開発環境には既にMySQLは立ち上がっている前提があるので、 既に立ち上がっているMySQLをそのまま利用する方法をとっています。 そこでテスト用のユーティリティクラスを紹介してみます。 package t::Utils; use strict; use warnings; use utf8; use lib './t/'; use Test::Fixtu
Perl 以外の言語でかかれたTCPサーバーをTest::TCPでテストする - tokuhirom's blog
Test::TCP の中で exec 発行すれば、groonga だろうと KT だろうと memcached だろうと、サーバープロセスのテストは簡単にできるのであって、サーバーごとにモジュールにする必要はない。以下は、groonga をテストする例。 Test::TCP は、さまざまなTCPサーバーのテストにつかわれており、さまざまな BK をふくんだ実装となっていて、これを再発明しようとすると、意外とめんどくさかったりするので、素直につかうとよいです。 use strict; use warnings; use utf8; use Test::More; use Test::TCP 1.08; use File::Temp (); use File::Which; my $bin = scalar which 'groonga'; plan skip_all => 'groonga
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
perl な web application のためのテスト情報
Hatena-Textbook/test-for-perl.md at master · hatena/Hatena-Textbook · GitHub