Why Don't You Do Your Test - Fukuoka Perl Workshop #18

テストを書か開発体制ない T

Fukuoka Perl Workshop #18Why Don t You Do Your Test? （社）Japan Perl Association 代表理事 (株) ライブドアプラットフォームグループ牧大輔

プロジェクト概要• Plack (Starman/Twiggy)• Mouse 使いまくり• Pickles (CTOがなかなかCPANにうｐしてくれない)• mysql, Q4M• Webアプリx3、ワーカーx1• エンジニア x 3人、バイトエンジニア x 1人 • もっとエンジニア欲しいなぁ∼ • 誰か応募してくれないかなぁ∼ • 俺に@ してくれると紹介できるんだけどなぁ∼

なんでテストを書かないか• そもそも今まであんまり書けって言われてない• テストが書きやすい環境が整ってない• 効果がわかりにくい

なんでテストを書くべきか• バグとかあった時に（正しく）「俺のせいじゃないよ」って言いたい• バグを直した時に他の動いてたものが壊れたりしないようにしたい• 早く家に帰って嫁とにゃんにゃんしたい

大枠の目標• テストを走らせる癖をつける• テストに適した環境を作る• テストを走らせるのが簡単な環境• テストを追加するのが楽な環境• 何をテストするのかわかりやすい環境• テストを書かない言い訳を許さない環境

Step 0とりあえず単位テストを書く

単位テスト• Webアプリのテストというと大仰な物を思い浮かべる人が多い• でも最初はとりあえず細かい部品の単位テストをしこしこ書く • 例： MyApp::Util 等に入っていそうな細かいツール• 「テストが存在する」事が重要

Step 1make test

とりあえず• git のマージマスターになってみる• master へのマージは全て自分が通す • git checkout -b merge • git pull origin new_branch • make test でテストが通るか確認 • それが通ったら、masterで git pull

初マージ後のテスト(＊) 画面はイメージです

というわけでマージ拒否• git pushする前のテストを必須条件に• マージマスターがテストを走らせる事によって • make testの存在を知らせる • make testが通らないコミットは許さない • 「テストされてない」ケースは別途対処

開発サイクルを作る• コードを書く → テスト• コードを書く → テスト• このサイクルを浸透させるには「テストを通らないなら受け付けない」は良いスタート• ただ、これをやるからにはちゃんとしたテスト環境を作る必要がある

Step 2テスト環境を整備

テスト環境でクリアするもの• データベース・関連サーバーの起動・終了・初期化• アプリケーションを外部から設定可能にする• テスト書きをなるたけ容易にする

サーバー類•テスト用のインスタンスを立ち上げる•すでに動いているものがあればそちらを指定可能にする

思ってるより楽• あなたが面倒くさいと思っている → 他の人もきっと面倒くさいと思っている• This is Perl! Perl界ではそういったものはすぐモジュール化、CPANに！

mysqld•Test::mysqld•特に何も意識せずにmysqldを立ち上げられる{ my $mysqld = Test::mysqld->new; $mysqld->start;}# $mysqld が解放されるとmysqldも落ちる

memcached•Test::Memcached•特に何も意識せずにmemcachedを立ち上げられる{ my $memd = Test::Memcached->new; $memd->start;}# $memd が解放されるとmemcachedも落ちる

それ以外• Proc::Guard• オブジェクトが残ってる間はプロセスが残る• オレオレ PSGIアプリとかはこれで（後述）

動かし方・・・？• ターミナルを一個あけてデーモン開始• make test• デーモンを停止・・・？• 嫌だ、面倒臭い

自動にして！• 他の人が走らせる時に手順を知らせないといけない（起動する順番とかに依存するかも？）• マージするときに面倒• 一度自動化してしまえば圧倒的にテストを走らせない理由を減らせる

make testでやろう• make testで自動的にサーバー類を走らせたい• 一部のテストだけ走らせることも可能にしたい• とにかく自動でやりたい

まず決め事を作る• 例えば $ENV{ TEST_DSN } があれば必ずそれを参照する事にする• Test::mysqldはこの値を埋めるのが仕事

便利関数を作っておくsub dbh(@) { my $dsn = $_[0] || $ENV{TEST_DSN}; my $user = $_[1] || $ENV{TEST_DBUSER}; my $password = $_[2] || $ENV{TEST_DBPASS}; my $attr = $_[3] || $ENV{TEST_DBATTR} || { RaiseError => 1, AutoCommit => 1, mysql_enable_utf8 => 1, }; require DBI; DBI->connect( $dsn, $user, $password, $attr );}my $dbh = dbh(); # 簡単！$dbh->prepare();

これだけでもそれなりに便利... > make test TEST_DSN=dbi:mysql:dbname=hoge• 外部から「このDBでテストしろ」ができる • 初期化しないとデータベースの状態が保証できないので、エラーになる可能性がある• これができたら次はDBを自動的に立ち上げる

mysqld を立ち上げる# t/start_daemons.plif (! $ENV{ TEST_DSN }) { require Test::mysqld; my %args = ( my_cnf => { skip-networking => , sql-mode => STRICT_TRANS_TABLES, } ); if ($ENV{TEST_MYSQLD}) { $args{mysqld} = $ENV{TEST_MYSQLD}; } my $mysql = Test::mysqld->new(%args); if (! $mysql) { die "Could not establish mysqld"; } $ENV{TEST_DSN} = $mysql->dsn(); # $mysql をどこかに取っておく必要がある（後述）}

make testと組み合わせる mysqld 起動 make test テスト mysqld 終了• こういうことをしたい• テストの前後にフックできるMakeﬁleを作りたい

Module::Install::TestTarget • ずっとこういうことしてた： •http://mt.endeworks.jp/d-6/2009/10/things-ive-done-while-using-test-mysqld.html • xaicron+gfxが書いた • テストターゲット毎に環境変数を設定 • Perlライブラリパスの追加 • テストを走らせる前後に任意のスクリプトを実行 • 走らせるテストを指定

設定default_test_target( includes => [ "/path/to/lib", "/another/path/to/lib" ], run_on_prepare => [ "t/start_daemons.pl" ], env => { FOO => 1, BAR => 2 }, tests => [ t/*/*.t ],);• start_daemons.pl でデーモン起動!• $mysqldが解放されると自動的にデーモン終了!

グローバルに登録する# t/start_daemons.plif (! $ENV{ TEST_DSN }) { require Test::mysqld; my %args = ( my_cnf => { skip-networking => , sql-mode => STRICT_TRANS_TABLES, } ); if ($ENV{TEST_MYSQLD}) { $args{mysqld} = $ENV{TEST_MYSQLD}; } my $mysql = Test::mysqld->new(%args); if (! $mysql) { die "Could not establish mysqld"; } $ENV{TEST_DSN} = $mysql->dsn(); our $TEST_MYSQLD = $mysql;# $main::TEST_MYSQLDに登録}

他のサーバーも同様にif (! $ENV{ TEST_MEMCACHED_SERVERS } ) { require Test::Memcached; my (@instances, @servers); for(1..5) { my $memd = Test::Memcached->new(); push @servers, sprintf 127.0.0.1:%d, $memd->option(tcp_port); push @instances, $memd; } $ENV{ TEST_MEMCACHED_SERVERS } = join ",", @servers; our @TEST_MEMCACHED_INSTANCE = @instances;}

外部からの設定• 「テストのための設定」を適用できないアプリだとテストを書けない • DBの繋ぎ先 • ファイルの参照先、保存先 etc• 同時に内部で使用するオブジェクトも設定可能にするべき

方針 1• 勝手にオブジェクト or 値を設定・作成しない • デフォルトの挙動としてはOK • 外部から指定できるようにするpackage MyApp::Foo;sub new { ... $self->{bar} = MyApp::Bar->new(); $self->{baz} = MyApp::Bar->baz(); $self->prepare( $self ); # 中で bar/bazを使う return $self;}my $foo = MyApp::Foo->new(bar => MyApp::Test::Bar->new()); # 使用されないッ$foo->{bar} = MyApp::Test::Bar->new(); # もう遅いッ

例解package MyApp::Foo;sub new { ... $self->{bar} ||= MyApp::Bar->new(); $self->{baz} ||= MyApp::Bar->baz(); $self->prepare( $self ); # 中で bar/bazを使う return $self;}my $foo = MyApp::Foo->new(bar => MyApp::Test::Bar->new()); # OK

方針 2• グローバル使わない！• 使ったとしても、use した時には影響無いように・・・ orzpackage MyApp::Foo;our $GLOBAL = 1;__PACKAGE__->setup( $GLOBAL );use MyApp::Foo; # もう$GLOBAL使っちゃってる・・・local $MyApp::Foo::GLOBAL = 10; # 意味ナシMyApp::Foo->setup( 10 ); # 動く「かも」しれないけど、2回呼んでる・・・

例解• 勝手に__PACKAGE__->setupとかそういうことはしない

方針 3• どうしても自動で判断するような事は%ENV等を使う• 最悪、local $ENV{VALUE} = foo できる

テスト書きを容易にする• どれだけ常用文 (boilerplate)を減らすかがキモ

例：さっきの便利関数sub dbh(@) { my $dsn = $_[0] || $ENV{TEST_DSN}; my $user = $_[1] || $ENV{TEST_DBUSER}; my $password = $_[2] || $ENV{TEST_DBPASS}; my $attr = $_[3] || $ENV{TEST_DBATTR} || { RaiseError => 1, AutoCommit => 1, mysql_enable_utf8 => 1, }; require DBI; DBI->connect( $dsn, $user, $password, $attr );}• これをMyApp::Testとかに入れておく

使用use Test::More;use MyApp::Test qw(dbh);my $dbh = dbh();# 色々テスト・・・done_testing();

よく使うチェックもまとめちゃう • 外部にHTTP接続をよく行うアプリなら・・・ sub http_request_ok { my $req = shift; my $ua = LWP::UserAgent->new(); my $res = $ua->request($req); my $ok = is( $res->code, 200, “Status is ok” ) && is( $res->content_type, “text/html”, “Content-Type is text/ html” ); if (! $ok) { diag $res->as_string; return (); } return $res; }

使用use Test::More;use MyApp::Test qw(http_request_ok);my $req = HTTP::Request->new( GET => “http://www.google.com” );if ( my $res = http_request_ok( $req ) ) { # さらにテスト ....}done_testing();

start_plackup• PSGIアプリを立ち上げるなら・・・sub start_plackup (@) { my %args = @_; my $app = $args{app}; my $port = $args{port} || Test::TCP::empty_port(); my @proc = ( plackup => (map { ("-I" => $_) } @INC), -p => $port, -a => $app ); my $proc = Proc::Guard::proc_guard(@proc);(contd)

start_plackup... my $cb = sub { my $request = shift; my $uri = $request->uri; $uri->scheme( "http" ) unless $uri->scheme; $uri->host( "127.0.0.1" ) unless $uri->host; $uri->port( $port ); my $ua = LWP::UserAgent->new; return $ua->request($request); }; Plack::Util::inline_object( port => sub { $port }, request => sub { $cb->(@_) }, pid => sub { $proc->pid }, );}

よく使う表現は関数に• 何かをしてその結果を待つ部分とか• 特定の場所に結果を取りに行く部分とか• 一部fork() しないといけない部分とか• 今後テストを書く必要がある人が考えなくてはいけない部分を先にモジュール化してしまう

何をテストするのか• 実はこれが一番難しい• これだけでも結構奥深いトピック

The Art Of Software Testing• クッソつまらない本だけどこういうのもあります

テストは量だけ多くてもしょうがない# lib/* のコード量$ find lib -type f -exec cat {} ; | wc -l 7041# t/* のコード量$ find t -type f -exec cat {} ; | wc -l 8687

考えてもわからない場合はコードに教えてもらう

Devel::Cover

t/cover.sh#!/bin/shcover -test -gcov -ignore_re ^(?:t|etc|modules)/• cover スクリプトを用意する（誰でも動かせるように）• 先にテストを自動化しておいたおかげでDBやキャッシュなどが整った状態で簡単にカバレッジを取ることができる！• (今さっき-gcovを使わないと一部XSを通したコードがカバレッジに含まれない事が判明）

coverageはあくまで目安• coverage情報は機械的な意味でのコードのテストされ具合を可視化できる• どれだけテストできてるのかがわかって効果が見える• ただ、潜在的なバグ（実装を間違えている、未実装の機能がある）等の指標には全くならない• そこは人間が考えるべき

まとめると

make testの流れデーモン類の起動初期データ（ﬁxtureの投入）make test テスト実行クリーンアップ

開発の流れ git レポジトリブランチにpush マスターにpush マスターからpull ブランチからpull 個人環境マージマスター開発テストマージテスト• 自動テストをがんばると開発者ごとで環境に関わらずテストを走らせる事ができる！• マージが多い日も安心！

• テストを走らせる癖をつける ➡ テストが通らない場合はマージしない• テストに適した環境を作る ➡ デーモン等の環境を自動的に作る• テストを走らせるのが簡単な環境 ➡ make testで全部が自動的に動くようにする• テストを追加するのが楽な環境 ➡ ツール類を充実させる• 何をテストするのかわかりやすい環境 ➡ カバレッジを一つの指標に• テストを書かない言い訳を許さない環境 ➡ ここまでお膳立てしてもらっているのにテストを書かないでバグ出したら超恥ずかしい！

テストを書か開発体制ない T

ご静聴ありがとうございました Questions?

Why Don't You Do Your Test - Fukuoka Perl Workshop #18

by lestrrat

Accessibility

Categories

Upload Details

Usage Rights

Statistics

Why Don’t You Do Your Test - Fukuoka Perl Workshop #18 Presentation Transcript