Harriet ー テストのときつかうにデーモンの取扱を簡単にするためのフレームワーク - tokuhirom's blog
https://github.com/tokuhirom/Harriet/https://metacpan.org/module/TOKUHIROM/Harriet-0.01/lib/Harriet.pmテストのときにつかう mysqld, memcached, stf, groonga あたりのデーモンを、.t 単位で起動していては遅くてかなわない。かといって、あらかじめ起動させておくというのも。。 というわけで prove のプラグインとしてよしなにする、みたいなのをがんばってかく、というような試みがおこなわれてきたわけですが、どうもめんどくさい。 なんか適当にやったらうまくうごく、っていうかんじのカジュアルなツールがほしいな、なんておもったりするわけですよ そこで、Harriet ってのをつくってみました。 なんかこう、t/harriet/mysqld.pl っていうファイル名でこん
はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
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
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 b
Testing Moose and Mouse for Any::Moose - Islands in the byte stream (legacy)
Or Re: RT #58255 If you use Module::Install, Module::Install::TestTarget will help you. In your Makefile.PL: use inc::Module::Install; ...; test_target test_moose => ( env => { ANY_MOOSE => 'Moose' }, alias_for_author => 'test', ); ...; The test_target() function defines a new make target "test_moose" (i.e. you can `make test_moose` in the above case) with the environment variable "ANY_MOOSE=Moose
Test::mysqld を別ウィンドウで立ち上げたら開発時の prove が快適過ぎる件 - Craftworks Tech Blog - Branch
id:xaicron 氏が紹介なされていました make test で Test::mysqld を永続化させる方法 を早速導入していたのですが、make test は速くなって便利なのですが、prove で 1 つずつテストをするときは、相変わらず mysqld を毎回、起動・終了するので時間がかかって開発時のストレスになります。 そこで、開発時には別ウィンドウで mysqld を立ち上げておいて、そこに接続しに行くようにすれば大分快適になると思い、実装してみました。 #!/usr/bin/env perl use strict; use warnings; use FindBin; use lib "$FindBin::Bin/../lib"; use File::Spec; use JSON; use Test::MyApp::mysqld; my $tempfile = File:
にひりずむ::しんぷる - make test で Test::mysqld を永続化させる方法
実際にどうやってんのかなーって話をあんまりしてなかったので。 まず、こんな感じのモジュールを t/lib/Test/MyApp/mysqld.pm とかで作って M::I::TestTarget の default_test_target() で `make test` を書き換えてやり、t/script/setup_mysqld.pl に とか書いてあげます。 それぞれのテストでは、Test::MyApp::mysqld->setup で mysqld を立ち上げるようにして置けば、 prove で個別にやった時は、それぞれ立ち上がる make test したときは、最初に立ち上げて、あとは使いまわす という感じになります。 ポイントとしては、 $ENV{TEST_MYSQLD} に Test::mysqld のデータ構造をそのまま JSON にして突っ込む Test::MyApp::m
Continuous Deployment to CPAN
Recently I was working on a refactor of one of my CPAN modules which, among other things, involved changing its name from Test::A8N to the specific Test::Story. Doing so made me think about the process I usually go through when I consider releasing a CPAN module. First, let me explain something about myself: I don’t like tedious or repetitive tasks. I hate having to do the same thing over and ov
はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
Perl Monger は Test::More の subtest が便利すぎるので頭にいれておくべきだと主張したい俺がいる件 - tokuhirom's blog.
Test::More の 0.94以後(2009-09-02)では subtest という機能が導入されており、これが非常に便利なのだが意外と利用されていないようなので、ちょっと宣伝させてもらいますね。以下は Data::Recursive::Encode のテストケースなのだが、似たようなケースが頻出するわりに、抽象化するのが面倒だし、わけわからなくなること必至であり、かつまた、こんなものを複数のファイルにわけていてはメンテナンスが面倒なことは考えるまでもない。チミチミと似たような数行のテストをかいたファイルを複数つくるぐらいならば、このように subtest の利用を考えるべきだとおもう。ただし、これも他のツール同様、なんにでも適用すればいいというものではなく、使い方をまちがえれば、関係ないものがゴッチャリはいった .t ができあがるので注意するべきだろう。 use strict; u
To repeat testing with different configuration - Islands in the byte stream (legacy)
構成条件を変えてテストを繰り返したいことがある。 たとえば，XSとPurePerlの両方の実装を持つモジュールなどはそうだし，Any::Mooseを使ったモジュールであれば $ENV{ANY_MOOSE} を変えてテストを繰り返したいと考えるのは当然だ。 この問題は，postamble()*1でMakefileにターゲットを追加することで解決できる。 さて，ここでは，開発者モードのときに $ENV{FOO_PUREPERL}=1 でテストをもう一度繰り返したいものとする。これには，Makefile.PLに以下のように記述すればよい。 # Makefile.PL use inc::Module::Install; # ... if(author_context){ # repeat testing # see also ExtUtils::MM_Any::test_via_harness()
Kazuho@Cybozu Labs: Perl のテスト用に MySQL 環境を自動で構築するモジュール Test::mysqld を書いた
ORM やウェブアプリケーション関連のライブラリなどのテストケースを書くにあたっては、 RDBMS へのアクセスが必要になります。しかし、SQLite のようなスタンドアローンのデータベースと比較すると、サーバ型データベースである MySQL に接続してテストを書くのは、既存の MySQL の権限設定やデータベース名を気にする必要があったりと、いろいろ不便です。そこで、MySQL のインスタンスをテンポラリディレクトリに自動生成し、テストが終わったら削除してくれる Perl モジュール Test::mysqld を書きました。こんな感じで使います。 use DBI; use Test::mysqld; use Test::More; my $mysqld = Test::mysqld->new( my_cnf => { 'skip-networking' => '' }, # TCP接続を
Test::Requires - Checks to see if the module can be loaded - tokuhirom's blog.
「あのモジュールがインストールされてなかったら、このテストはスキップな」っていう設定をしたいときは結構あるんだけどもこれをちゃんと実装するのは意外と難しい。そして、設定が繁雑になりがちだ。 use Test::More; plan "this test requires HTTP::MobileAttribute" unless eval "use HTTP::MobileAttribute; 1;"; plan tests => 10; みたいなの毎回かくのめんどくね?plan を先にかいとくとエラーになるし。っちうわけで、モジュールにしてみましたよ、と。今回つくった Test::Requires ていうのをつかうと、以下のようにかけますよ、と。 use Test::More tests => 10; use Test::Requires qw/ HTTP::MobileAttribut
Test::Cukes - A BBD Tool inspired by Cucumber - gugod's blog
Cucumber , the BBD tool, is something that is really brilliant. I wrote Ruby code for my work too and I tried to used this tool with watir. Again, Brilliant. And turns out there are cucumber implementations in Perl too: http://search.cpan.org/dist/cucumber/ http://search.cpan.org/dist/Test-Cucumber/ http://github.com/kesor/p5-cucumber/tree/master But they don’t seem to work seamlessly with TAP-fam
RSpec vs. Test::More
Yesterday, someone pointed me in the direction of the RSpec testing framework for Ruby: http://blog.davidchelimsky.net/articles/2007/05/14/an-introduction-to-rspec-part-i I suggest reading the post, if only to enjoy literary constructions along the lines of: Behaviour Driven Development is an Agile development process that comprises aspects of Acceptance Test Driven Planning, Domain Driven Desig
Test-Behaviour-Spec-0.01 を CPAN へ登録 - Tociyuki::Diary
Perl のテストで Behaviour Driven Development (BDD) して遊ぶためのモジュールを CPAN に登録しました。ご利用ください。 ⇒ http://search.cpan.org/~tociyuki/Test-Behaviour-Spec-0.02/ 0.01 の POD の使用例コードにセミコロンが一ヶ所抜けていたので、修正しました。コード本体は 0.01 と同じです。 ⇒ http://search.cpan.org/~tociyuki/Test-Behaviour-Spec-0.01/ Test::Behaviour::Spec は、ふるまいを記述するための述語 describe、it、spec をサブルーチンとして使えるようにするだけで、いっさい Test::More 等への変更をおこないません。そのため、従来のどのようなテストにも、ふるまい記述を
DBD::Mock を使ったテスト - 日向夏特殊応援部隊
DBD::Mock は DBI のドライバの一つで、DBI を使ったプログラムで意図的な状態を作る事が出来ます。 と言う訳でメモ程度に書いて行きます。 データベースハンドルの取得 use strict; use warnings; use Test::More; use DBI; plan tests => 3; my $dbh = DBI->connect('dbi:Mock:', '', '', +{ AutoCommit => 0, RaiseError => 1 }); ok($dbh, 'Create database handle'); isa_ok($dbh, 'DBI:db'); is($dbh->{Driver}->{Name}, 'Mock', 'Driver information'); で、普通に Database Handle が取れます。 SELECT してる箇
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
CPAN Testers Matrix
http://d.hatena.ne.jp/tokuhirom/20091229/1262083201
https://blog.8-p.info/2009/12/test-synchronized