2013年01月16日makopi23のブログmakopi23が日々の生活で感じたことを気ままに綴るブログです。13」に参加してきました。connpass(告知サイト)http://connpass.com/event/1623/togetterhttp://togetter.com/li/439828以下の書籍をターゲットとした読書会なのです。Ziade商品詳細を見る場所はいつもの目黒で、参加者は15人くらいでしょうか。テスト駆動開発」ということもあり、とても興味がありました。最近は以下の書籍でちょうど勉強しているトコですし。商品詳細を見る通称、GOOS本。オンラインの写経会にも参加してますし、先日もこのネタでDevlove2012のブログ書きました。商品詳細を見るこちらは最近購入して写経している最中。横浜である読書会に参加しようと思って。あと、GOOS本を進める上でも有効かな、と思って進めてます。いうことで、以下は当日の自分用メモ。第一期のエキPy11章のQ&Aがある。http://www.freia.jp/taka/docs/expertpython/reading/14.html「エキスパートPythonプログラミング」の訳者の一人である稲田さんがTDDに関するブログ記事を書いている。http://methane.hatenablog.jp/entry/2013/01/08/py.test_%E3%81%A7_TDD_%E3%81%97%E3%81%A6%E3%81%BF%E3%82%8Bプロダクトコードが変更になると、そのテストコードも修正が必要になることが多い。テストコードの修正が膨大でメンテが困難になるなど、TDDが負の遺産になることがある。Selenimuというツールがある。Webアプリケーションのテストに特化したツール群らしく、SeleniumがWebブラウザを操作してテストを実行してくれるらしい。http://oss.infoscience.co.jp/seleniumhq/index.htmlFIT/FitNesseというツールがある。http://jasst.jp/archives/jasst05e/pdf/S5-B-1.pdfExcelで入出力の期待値を表形式で書くことで、画面遷移のテストができるらしい。お客さんがシステムに詳しくない場合でも、お客さん自身でテストデータを作ることが可能、というのがコンセプトらしい。テストツールは用途に合わせて選ぶべき。「ひたすらプロダクトコードを書いて、途中からテストを書く」という進め方を取っているという紹介あり。テストコードはプロダクトコードが変わると壊れることがあるので、いきなり最初からは書かないという思想。リグレッションテストは途中からでも書けるので、最初から書かなくても大丈夫、という思想。TDDをやる場合は、ポイントを絞る。TDDの恩恵がある部分に対してやる。プロジェクトにTDDを導入する際は、TDDを自分でやってみせるのがいいのでは。テストコードは、プロダクトコードを書いた自分自身が書かないと成長しない。テストコードとプロダクトコードを別の人が書くのは意味がないのでは。単体テストはおまけ、という意見もある。プロダクトコードとテストコードを書く時間の割合は、テストコードを書く時間の方がかなり多いのでは。数倍になることもある。a+badd関数を上記のように定義して、コマンドラインからhelp(add)と実行すると、"""で囲んだ内容がその関数の仕様として表示されるようになる。(ソースのコメントがドキュメントになる。Javadocのようなもの?)doctestプロダクトの使い方をわからせるために便利。(ドキュメントの中にテストが書いてある)ドキュメントに「文章」と「使い方」をペアで書いておき、「使い方」がテストとして動作する。ドキュメントに書いた「使い方」がそのままテストとなるので、ドキュメントとコードが乖離しない。プロダクトコードが変わるとドキュメントのテストが失敗して、プロダクトコードとドキュメントの乖離がすぐ検知できるので。清水川さんのブログに、TDDのハンズオンについて書いた記事がある。http://www.freia.jp/taka/docs/pyhack5/exercise.htmldoctestは受託開発では使われないかも。ドキュメントにテストコードを書くことになるが、受託だと納品が発生するので。受託開発ではなくライブラリ開発なら、doctestは使えるかも。アプリ開発に使うのは時間の無駄。テストジェネレータは資産になるが、単体テストは負債でしかない、という意見あり。FIT/FitNesseとかCucumberとかを使ってテストを自然言語で書くのは、実は結構大変で負債、という意見あり。FIT/FitNesseは受け入れテストで表形式でテストデータを作成できるが、お客さんにその表を作成してもらえない場合が多い。要件さえ決めきれないお客さんなのに、テストデータなんか書けるか、という問題がある。noseはunittestよりテストを書きやすいプロダクトコードにassert文を埋め込むこともある。デバッグ時はテストコードを有効にし、リリースする場合に削除することができる。アプリは無理だけどライブラリなら使えるかも。単体テストはsetupとteardownで独立性を持たせることが基本。順序性を持ったテストは良くない。「エキスパートPythonプログラミング」の訳者の一人である森本さんがTDDに関するブログ記事を書いている。やってみた」http://d.hatena.ne.jp/t2y-1979/20120209/1328740274森本さんがPytestの原文ドキュメントを翻訳している。http://pytest.org/latest-ja/noseとpytestでは、テストランナーがテストを探す順序が異なる。検索の正規表現が違うらしい。pytestよりnoseのプラグインの方が使いやすい。Pythonで今からテスト書くなら、pytestの方がnoseよりいいかも。森本さんの日本語マニュアルがあるし、QuickCheckというツールがあるし、テストカバレッジの機能が追加されたし。今ならpytest一択という意見あり。noseはpytestに比べプラグインが豊富という利点がある。Python標準のテストドキュメントあるが、わかりにくいので、pytestのドキュメントを読んだ方がいいかも。外部依存をなくしたテストをするのがスタブとモック。PyPIにmockというライブラリがある。Python3.3でmockが標準で取り込まれた。minimockはクセがあるので、Pythonに標準で取り込まれたmockの方を使うほうがいいかも。mockの良さは、テストコードを書かないとわからない。Patternsという書籍がある。PatternsというWebがあり、これをブラッシュアップしたのが書籍になった。Webで無料で観れるが、本を買った方が良い。Patternsの一部を翻訳している。https://dl.dropbox.com/u/284189/xunitpatterns.com-ja/Test%20Double%20Patterns.html「テストダブル」という用語を理解しておくと、他の言語のテストとかでいろいろ役立つことがある。「テストダブル」テストがダブル、つまり代役を用意する。俳優がスタントマンと交代してやる、というイメージ。「テストスパイ」テストの順序とか、テストが何回呼ばれたかとかを後で検証できる。Patternsは、テストのパターンを知るには良い本。(電話帳より厚いらしい)テスト用語に迷ったら読むと良い本。Patternsの「テストスタブ」に書いてあることしかできない。Patternsにある用語の大体全部できる。DDD(ドキュメント駆動開発)やりすぎよくない境界値テストを書こうとすると破綻する21時からはビアバッシュ&LTタイムです。LTネタ:QuickCheckについてテストスイート用のテストケースを生成してソフトウェアテストを行うための、Haskellで書かれたコンビネータライブラリらしく、多数の言語に移植されているらしい。wikipedia)いわゆる、テストジェネレータ。データ型の定義域に存在するランダムデータを使ったテストを自動生成し、繰り返しテストしてくれるらしい。前回テストに失敗したテストデータをQuickCheckが覚えていて、その近辺のデータを使ったテストを機械学習で生成し再テストもしてくれるらしい。(shrink:シュリンク)QuickCheckが生成したテストを行うだけでカバレッジが90%を超えることもあるとのこと。QuickCheckの商用ライセンスは、年間300万円/人らしい。3人月のコストでテストの効率が劇的に向上する可能性がある、という事実と天秤にかけることになる。★感想:本に無いことを非常に多く学べた勉強会でした。社外の勉強会に参加する意義はここにあると思います。脱線した内容が濃いのです。あと、TDDはテストを書いた分だけ上手になる、という話が出ましたが、先日のDevlove2012でもt-wadaさんが同じことをおっしゃってました。今はTDD関連の書籍の写経やってますが、とにかく手を動かしてテストコードを書く練習をまずは繰り返してみようと思います。あと、会社でやってるユニットテストで、順序性を持ってしまっているものを見かけますが、これもダメだなーと再認識しました。setupとteardownが必要そうです。LTで紹介されたQuickCheckも、実に興味深いですねー。講師の清水川さん、運営者さん、会場提供者さん、有意義なお時間をありがとうございました。コメント(0)|-->プロフィールAuthor:makopi23某メーカーでソフトウェアエンジニアやってます。趣味はバスケ、筋トレ、プログラミングなどなど。