connpass（告知サイト）
http://connpass.com/event/1623/
togetter
http://togetter.com/li/439828
以下の書籍をターゲットとした読書会なのです。
 | エキスパートPythonプログラミング (2010/05/28) Tarek Ziade 商品詳細を見る |
場所はいつもの目黒で、参加者は15人くらいでしょうか。
今回のテーマは「第11章 テスト駆動開発」ということもあり、とても興味がありました。
最近は以下の書籍でちょうど勉強しているトコですし。
 | 実践テスト駆動開発 テストに導かれてオブジェクト指向ソフトウェアを育てる (Object Oriented SELECTION) (2012/09/14) Steve Freeman、Nat Pryce 他 商品詳細を見る |
通称、GOOS本。オンラインの写経会にも参加してますし、先日もこのネタでDevlove2012のブログ書きました。
 | JUnit実践入門 ~体系的に学ぶユニットテストの技法 (WEB+DB PRESS plus) (2012/11/21) 渡辺 修司 商品詳細を見る |
こちらは最近購入して写経している最中。横浜である読書会に参加しようと思って。
あと、GOOS本を進める上でも有効かな、と思って進めてます。
ということで、以下は当日の自分用メモ。
- 第一期のエキPy11章のQ&Aがある。
- 「エキスパートPythonプログラミング」の訳者の一人である稲田さんがTDDに関するブログ記事を書いている。
- プロダクトコードが変更になると、そのテストコードも修正が必要になることが多い。テストコードの修正が膨大でメンテが困難になるなど、TDDが負の遺産になることがある。
- Selenimuというツールがある。Webアプリケーションのテストに特化したツール群らしく、SeleniumがWebブラウザを操作してテストを実行してくれるらしい。
- FIT/FitNesseというツールがある。
http://jasst.jp/archives/jasst05e/pdf/S5-B-1.pdf
Excelで入出力の期待値を表形式で書くことで、画面遷移のテストができるらしい。
Excelで入出力の期待値を表形式で書くことで、画面遷移のテストができるらしい。
お客さんがシステムに詳しくない場合でも、お客さん自身でテストデータを作ることが可能、というのがコンセプトらしい。
- テストツールは用途に合わせて選ぶべき。
- 「ひたすらプロダクトコードを書いて、途中からテストを書く」という進め方を取っているという紹介あり。
- テストコードはプロダクトコードが変わると壊れることがあるので、いきなり最初からは書かないという思想。
- リグレッションテストは途中からでも書けるので、最初から書かなくても大丈夫、という思想。
- TDDをやる場合は、ポイントを絞る。TDDの恩恵がある部分に対してやる。
- プロジェクトにTDDを導入する際は、TDDを自分でやってみせるのがいいのでは。
- テストコードは、プロダクトコードを書いた自分自身が書かないと成長しない。テストコードとプロダクトコードを別の人が書くのは意味がないのでは。
- 単体テストはおまけ、という意見もある。
- プロダクトコードとテストコードを書く時間の割合は、テストコードを書く時間の方がかなり多いのでは。数倍になることもある。
- helpコマンド
def add(a, b):
""""return a+b"""
return a+b
add関数を上記のように定義して、コマンドラインからhelp(add)と実行すると、"""で囲んだ内容がその関数の仕様として表示されるようになる。（ソースのコメントがドキュメントになる。Javadocのようなもの？）
""""return a+b"""
return a+b
add関数を上記のように定義して、コマンドラインからhelp(add)と実行すると、"""で囲んだ内容がその関数の仕様として表示されるようになる。（ソースのコメントがドキュメントになる。Javadocのようなもの？）
- doctest
プロダクトの使い方をわからせるために便利。（ドキュメントの中にテストが書いてある）
ドキュメントに「文章」と「使い方」をペアで書いておき、「使い方」がテストとして動作する。
ドキュメントに書いた「使い方」がそのままテストとなるので、ドキュメントとコードが乖離しない。
プロダクトコードが変わるとドキュメントのテストが失敗して、プロダクトコードとドキュメントの乖離がすぐ検知できるので。
ドキュメントに「文章」と「使い方」をペアで書いておき、「使い方」がテストとして動作する。
ドキュメントに書いた「使い方」がそのままテストとなるので、ドキュメントとコードが乖離しない。
プロダクトコードが変わるとドキュメントのテストが失敗して、プロダクトコードとドキュメントの乖離がすぐ検知できるので。
- 清水川さんのブログに、TDDのハンズオンについて書いた記事がある。
- doctestは受託開発では使われないかも。ドキュメントにテストコードを書くことになるが、受託だと納品が発生するので。受託開発ではなくライブラリ開発なら、doctestは使えるかも。アプリ開発に使うのは時間の無駄。
- テストジェネレータは資産になるが、単体テストは負債でしかない、という意見あり。
- FIT/FitNesseとかCucumberとかを使ってテストを自然言語で書くのは、実は結構大変で負債、という意見あり。
FIT/FitNesseは受け入れテストで表形式でテストデータを作成できるが、お客さんにその表を作成してもらえない場合が多い。要件さえ決めきれないお客さんなのに、テストデータなんか書けるか、という問題がある。
- noseはunittestよりテストを書きやすい
- プロダクトコードにassert文を埋め込むこともある。デバッグ時はテストコードを有効にし、リリースする場合に削除することができる。アプリは無理だけどライブラリなら使えるかも。
- 単体テストはsetupとteardownで独立性を持たせることが基本。順序性を持ったテストは良くない。
- 「エキスパートPythonプログラミング」の訳者の一人である森本さんがTDDに関するブログ記事を書いている。
「データ駆動テストを nose と pytest でやってみた」
http://d.hatena.ne.jp/t2y-1979/20120209/1328740274
http://d.hatena.ne.jp/t2y-1979/20120209/1328740274
- 森本さんがPytestの原文ドキュメントを翻訳している。
- noseとpytestでは、テストランナーがテストを探す順序が異なる。検索の正規表現が違うらしい。
- pytestよりnoseのプラグインの方が使いやすい。
- Pythonで今からテスト書くなら、pytestの方がnoseよりいいかも。森本さんの日本語マニュアルがあるし、QuickCheckというツールがあるし、テストカバレッジの機能が追加されたし。今ならpytest一択という意見あり。ただ、noseはpytestに比べプラグインが豊富という利点がある。
- Python標準のテストドキュメントあるが、わかりにくいので、pytestのドキュメントを読んだ方がいいかも。
- 外部依存をなくしたテストをするのがスタブとモック。
- PyPIにmockというライブラリがある。またPython3.3でmockが標準で取り込まれた。
- minimockはクセがあるので、Pythonに標準で取り込まれたmockの方を使うほうがいいかも。
- mockの良さは、テストコードを書かないとわからない。
- xUnit Test Patternsという書籍がある。
 | xUnit Test Patterns: Refactoring Test Code (Addison-Wesley Signature Series (Fowler)) (2007/05/21) Gerard Meszaros 商品詳細を見る |
xUnit PatternsというWebがあり、これをブラッシュアップしたのが書籍になった。
Webで無料で観れるが、本を買った方が良い。
Webで無料で観れるが、本を買った方が良い。
- 清水川さんがxUnit Test Patternsの一部を翻訳している。
- 「テストダブル」という用語を理解しておくと、他の言語のテストとかでいろいろ役立つことがある。
「テストダブル」
テストがダブル、つまり代役を用意する。俳優がスタントマンと交代してやる、というイメージ。
テストがダブル、つまり代役を用意する。俳優がスタントマンと交代してやる、というイメージ。
- 「テストスパイ」
テストの順序とか、テストが何回呼ばれたかとかを後で検証できる。
- xUnit Test Patternsは、テストのパターンを知るには良い本。ただ分厚くて重い。（電話帳より厚いらしい）
テスト用語に迷ったら読むと良い本。
- minimockは、xUnit Test Patternsの「テストスタブ」に書いてあることしかできない。
- Python標準のmockは、xUnit Test Patternsにある用語の大体全部できる。
- DDD（ドキュメント駆動開発）
- やりすぎよくない
- 境界値テストを書こうとすると破綻する
21時からはビアバッシュ＆LTタイムです。今日はお寿司でした。
LTネタ：QuickCheckについて
- テストスイート用のテストケースを生成してソフトウェアテストを行うための、Haskellで書かれたコンビネータライブラリらしく、多数の言語に移植されているらしい。(by wikipedia)
- いわゆる、テストジェネレータ。
- データ型の定義域に存在するランダムデータを使ったテストを自動生成し、繰り返しテストしてくれるらしい。
- 前回テストに失敗したテストデータをQuickCheckが覚えていて、その近辺のデータを使ったテストを機械学習で生成し再テストもしてくれるらしい。（shrink：シュリンク）
- QuickCheckが生成したテストを行うだけでカバレッジが90%を超えることもあるとのこと。
- QuickCheckの商用ライセンスは、年間300万円/人らしい。3人月のコストでテストの効率が劇的に向上する可能性がある、という事実と天秤にかけることになる。
★感想：
本に無いことを非常に多く学べた勉強会でした。やっぱ社外の勉強会に参加する意義はここにあると思います。脱線した内容が濃いのです。
あと、TDDはテストを書いた分だけ上手になる、という話が出ましたが、先日のDevlove2012でもt-wadaさんが同じことをおっしゃってました。やっぱ、そうなんですかねー、なるほどなぁ。
今はTDD関連の書籍の写経やってますが、とにかく手を動かしてテストコードを書く練習をまずは繰り返してみようと思います。
あと、会社でやってるユニットテストで、順序性を持ってしまっているものを見かけますが、これもダメだなーと再認識しました。setupとteardownが必要そうです。
LTで紹介されたQuickCheckも、実に興味深いですねー。
講師の清水川さん、運営者さん、会場提供者さん、有意義なお時間をありがとうございました。
- 関連記事
-
- 「第7回 スタートHaskell2（最終回）」に参加しました
- 「エキスパートPythonプログラミング読書会 第二期 13」に参加しました
- 「DevLOVE Conference 2012」に参加しました ～其の弐～
