Docker コンテナで MySQL を使ったテストの高速化 - stfuawsc
全国1億2000万の Docker ファンの皆さんこんにちは。 MySQL の起動がとてつもなく遅いのは有名な話。 ところが Docker コンテナの起動はなかなか早いので、 MySQL を使っているようなテストを高速化するケースで有用性が認められるのではないかと思って PoC を書いてみた。 （宣伝）こういった話も含めて YAPC でトークしたいので SNS 等で upvote お願いします： ( ✌'ω')✌ 楽しいモデル層開発 - YAPC::Asia Tokyo 2014 （宣伝おわり） MySQL を使ったテスト MySQL を使ったテストをする場合、だいたい次の 2 パターンになる。 MySQL をテストのたびに起動してクリーンな状態で使う ローカルにデーモンとして起動した MySQL に接続して DROP TABLE や TRUNCATE でクリーンな状態にして使う だけど、
不必要なテスト - パルカワ2
テストするべき項目、テストするとき考えると思う。 一つのメソッドに対して、テストするべき項目が多すぎるとそのメソッドがやたらでかいとか、不必要な部分までテストしてるとかだと思う。 メソッドがやたらでかい場合は、切り分けるし、不必要なテストは、消すべきだと思う。 あるパラメータからデータを作って、さらにそのデータを使って計算するみたいなの全部まるっと一つにまとめるとかよくされる。何をしているかで分類すると2つやってることがある。メソッドは、一つのことをやればいいと思う。だから、あるパラメータからデータを作るメソッド、データを受け取って計算するメソッドみたいな感じで分けるのが良いと思っている。 sub hoge { $self->fuga() # hoge処理 } 不必要なテストは、こういうhogeメソッドがあったとして、fugaのテストまで、hogeのテストでやってしまうみたいなの見かける。
perl な web application のためのテスト情報 を #yapcasia で話してきました - soh335 memo
yapc::asia 2013 で perl の test 回りの話をしてきました。 去年からテストについて色々取り組んでいた所で、実際どういうモジュールでどうコードを書いてるかっていう説明が出来たと思います。 他の人がどういうテストを書いているかとかも気になるので、なにか気になったりしたら話したりしたいです。 継ぎ足しでスライドを作っていたら、 test::mock::guard のコードの説明がなくなっていて、なくなっていたと思ったら後ろから出てきたり、久しぶりに人前で喋ったせいか、珈琲のストローとマイクを間違えて喋ったりしました。 335さんこういうキャラの人だったのか。— ダメ人間 (@dameninngenn) September 20, 2013 335「びっくりだ！」聴衆（こっちがだ） #yapcasia— ひさいち (@hisaichi5518) September 20,
Test::Moreのsubtestで困っていること - $shibayu36->blog;
最近はperlでテスト書く時はTest::Classを使うようにしている。その理由の一つとして、subtestだけのテストだと少しだけ困ることがあるからだ。 具体的には以下の事がある。 subtestは書かれている順に実行されるため、前のテストの状態に依存したコードが書かれがち 特定のsubtestだけを実行するのが面倒 前のテストの状態に依存したコードが書かれがち 僕の中では、テストが前のテストの状態に依存しないようにすべきと思っている。各テストの依存度が増えると、その後テストを追加したいときにコードの見る範囲が増え、テストが書きづらくなってしまうからだ。 しかし、subtestは単に書かれた順にテストが実行されるので、前のテストの状態に依存したコードが書きやすいと思っている。例えば以下の様なコードが書かれがち(少し極端な例だが)。 use Test::More; # insert_en
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
Test::MockTime - 時間にまつわるtest - Articles Advent Calendar 2011 Test
はい、kawamotoです blogは書いているとはとても言えないぐらいサボっております。 右も左もわからぬひよっこですので奇をてらわずにTest::名前空間のモジュールの紹介をしようと思います。 Test::MockTime は testの最中に実行される time, localtime, gmtime などの時間に関する関数の振る舞いを書き換える便利なモジュールです。 以下のような症状によく効きます。 テストの期待する結果に時刻を入れたいが固定の値を指定できない。 外部のコンポーネントに存在する、時間で変動する要素に依存しないテストを書きたい(たとえば MySQL で時系列のパーティションを使っているなど) テストを実行するたびに経過時間が変動してtestが通ったりこけたりする 使い方はこちらの記事でも説明されていますが、 $ cat ~/test.pl use feature qw(
ベンチどうしますか？ - Articles Advent Calendar 2011 Dbix
どうもnekokakです。 みなさんDBIを使っているコードのベンチマークってどうしてますか？ SQLのチューニングであればいいのですが、ロジックのベンチマークを取りたい時に 実際にdatabaseにクエリなげてしまうと、ネットワーク通信等が発生し、細かいロジックのチューニングの邪魔になることがあります。 たとえば私はTengのチューニングをするときに、バックエンドのdatabase性能なんてどうでもよくて、 プログラムの性能をみたいわけです。 そんなときに便利なのがTest::Mock::Guardです。（え Testというnamespaceにありますが、やっていることはコードをさしかえることなので これをつかって実際にデータベースにクエリなげるところとかをフガフガします。 例えばTengのベンチマークを取る時に試したコードは以下のようなものです。 #! /usr/bin/perl us
テストデータどうしてますか？
This document discusses using data factories to generate test data in Perl. It shows how to: 1. Construct a test fixture from a YAML file to populate a database with sample data. 2. Create a factory method that generates sample records on demand with random or specified field values. 3. Configure a data factory object to connect to a database and define the factory method for generating rows in a
Testing Web Application 2011秋 - tokuhirom's blog
とにかく楽に、お気軽に。お気軽にテストを追加できて、お気軽にテストを実行できる。というのがなによりも重要です。 追加しようとおもったときに「どう追加したらいいかわからない」という状況になりがちなので、あらかじめいろいろな構成要素ごとにテストをひととおりかいてみるというのも重要だとおもいます。O/R Mapper のクラスのテストとか、model のテストとか、コントローラのテストとか、JSON API のテストとか。。 ExtUtils::MakeMaker でテストをうごかさないExtUtils::MakeMaker を素でつかうと blib/ とかつかってきてうざいので、Makefile.PL に以下のような hack をほどこしてあります。ウェブアプリケーションで blib/ とかにコピーする必要ないですよね。実運用でも blib/ でうごかさないし、インストールもしませんし。 #
Perlで抽象クラス的なものをテストしたい場合どうするか - 愛と勇気と缶ビール
例えば、以下のような抽象クラス？的なモジュールがあるとしねえ。 package AbstractClass; sub call { my ($self, @args) = @_; # なんか色々前処理とかする $self->do_something($params); } # ここから後にdo_somethingの実装はない (いわゆる抽象メソッド的なアレ) plugin的な仕組みを用意したいとき、こんなコードが出てくると思います。「この抽象クラスを継承したクラスで、do_somethingを実装する」ということにして、その中身はクラスごとに違う、と。使う側は常にcallを呼び出して、共通する前処理をcallの中でやってもらって後、サブクラスのdo_somethingに処理が移る。 で、このcallメソッドのtestをしたいんだけど、このAbstractClassをそのままnewしてcal
Jenkins はじめました + ほか3つ - mixi engineer blog
こんにちは。加藤和良です。 まずあの話を書いて、それを前提にあの話を書いて、みたいなキューが筆者の中にはあったのですが、正直キューの先端につまってる話はだんだん個人的な関心および記憶がうすれてきました! 昔のはなしですからね。 というわけで、最近のまとめをさらっと書いて、新しいネタをすぐ書ける状態にリセットしたいと思います。 Jenkins mixi ではバージョン管理システムとして Subversion を使っています。安定した、いつでもリリースできるバージョンを trunk に、開発中の機能は branches 以下に作業ブランチをつくり、レビューや QA などの後に trunk にマージする、という運用です。 Buildbot はこのうち trunk だけを追っていたのですが、徐々に「このブランチも Buildbot で追うようにして、結果をこの IRC チャンネルに書きこんでほしい
テスト駆動開発のすすめ - 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
Smart::Commentsでモジュールにサンプルコードを仕込む - Islands in the byte stream (legacy)
ソースコードを読んでいると、関数の引数や戻り値の具体的な例がほしいと思うことがよくある。。そこで、実行可能なコメントを仕込むモジュールであるSmart::Commentsを使って、モジュール内にテストを兼ねたサンプルコードを仕込めばいいのではないかと考えた。これにより、開発者にとっては簡単なテストコードとして動き、読者にとっては具体例となるコードを簡単にソースコード内に埋め込むことができる。 package MyUtil; use strict; use warnings; use parent qw(Exporter); our @EXPORT = qw(add); use if __FILE__ eq $0, 'Smart::Comments'; ### assert: add(10, 20) == 30 sub add { my($a, $b) = @_; ### add(a, b)
App::Prove::Plugin::Growlを書き直してみた - すぎゃーんメモ
もう1年以上になりますが「proveコマンドを実行したときの結果とかをGrowlで通知するプラグイン」というのを書いていて、 proveコマンドの完了をGrowl通知するプラグインを書いてみた - すぎゃーんメモ そのときはMac以外のプラットフォームでどうするの、とか何とかでうやむやなまま放置していたのだけど、その後Growl::Anyというモジュールが出来て、今はそのあたりはスッキリしていますね。 Big Sky :: MacでもLinuxでもWindowsでもTwitterのhome_timelineをGrowl Growl::Anyが新しくなりました - Islands in the byte stream ので、Growl::Anyを使って通知してくれるように書き直してみました。 https://github.com/sugyan/App-Prove-Plugin-Growl 実
Test::Mock::Guard Released - 日向夏特殊応援部隊
さっき nekokak さんと xaicron さんにそそのかされて Test::Mock::Guard ってモジュールを書いてみました。 そもそも Perl には Test::MockObject と言う汎用の Mock モジュールがあるんですけど、あれこれ余計な機能がたくさんついてたり Mock 化すると多分元に戻せないと言うのがあってもっとシンプルな奴がほしいなと思って作ってみた次第です。SYSNOPSIS のコピペですけど、 use Test::More; use Test::Mock::Guard qw(mock_guard); package Some::Class; sub new { bless {} => shift } sub foo { "foo" } sub bar { 1; } package main; { ### このスコープでは Mock 化されてる my
外部APIを含めたWebアプリのテストをしてみる - Perl勉強メモ アルパカDiary出張版
外部APIを用いたWebアプリのコントローラテストについて。 たとえば 数値の２乗を結果として返すAPIサーバ があるとして、 そのAPIを利用した結果をHTMLとして出力するアプリケーション を考えてみます。 しかし、このように外部APIサーバを用いるとテストが難しくなります。 もしかしたらアクセスコントロールされているかもしれませんし、 メンテナンスされているかもしれませんし、 オフラインだとそもそもテストできないですよね！ そこで外部APIサーバを振舞うplackサーバをローカルで立ち上げて それをproveで利用できるといいかも。 というわけでそのような環境を作ってみます。 サンプルWebアプリ *1 まずは /api に アクセスすると 外部APIサーバにアクセスしてその結果を返すだけのコントローラを書いてみます。 $host はテストからコントロールできるように環境変数をみてい
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
モダンPerlリファクタリング #yapcasia
PerlでTDD(テスト駆動開発)するなら覚えておきたいCPANモジュール群 | hirobanex.net
Why Don't You Do Your Test - Fukuoka Perl Workshop #18
