doctestにみるアーキテクトとプログラマの協調作業
最近 Python Testing Beginners Guide 読んでます。
ここのdoctestの入り方が非常に面白かったので、ちょっと紹介と考察をまとめてみようと思い書いてみる。
Python Testing Begginers Guideって何
まずこの本をさくっと。
Packt Publishingが発行してるPythonのテスト手法のHow to本。
Expert Python Programmingのテスト手法、TDD、CIなどをもっと詳細かつ分野を特化した感じ。
Pythonのテスト技法をもっと知りたいって方はおすすめな１冊。
英語で書いてあるけどサンプルコードが豊富なので写経するだけでもある程度わかるかも。
以上宣伝乙。
doctestの章について
この本のdoctestの解説は
doctest概要・機能説明→振る舞いの設計→コード実装→リファクタリング*1→仕様変更→以下略...
と言った具合に進む*2
設計の段階ではdocstringにdoctestのコードを埋めると言った方法ではなく、テキストファイルdoctestのコードを記述する。
そしてPythonから実行するには、
を実行しなさいと書いてある。
python -m doctest doctest_file.txt
これだけみれば、本当にコードを書いて実装しているという感じがしない。
いやdoctestを記述するテキストファイルには思いっきりコード書くんだけどさ。
でも振る舞いしか書かないから、実装しているという感じはしない。
doctestはなぜdoctestなのか
doctestがdoctestと言われる由縁はズバリ
docstringに直接書き、仕様書になるから
だろう。
恥ずかしながらテキストファイルにdoctestを書くっていうのは知らず（or あまり使わず忘れていた）、もしかしたらこれってウォーターフォールモデル開発でのアーキテクトとの接点を作るための強力なツールになるんじゃないかと思った。
とりあえず例でも
風呂入っていたときに妄想していたストーリー。
アーキテクト（以下ア）「こんなモジュール作ってくれないかな？仕様はmodule.txtを確認してくれ。」
プログラマ（以下プ）「了解です。doctest形式にちゃんとなってるっぽいですね。」
ア「それじゃ任せた。」
実装完了
プ「できました。テスト結果はいつもの方法で見てください。」
ア「問題ないようだな。ところでプログラマ君、このモジュールにxxxの機能を追加したいんだよ。」
プ「えっ」*3
ア「追加する仕様は別途ファイルに書いておいた。module_add_xxx.txtを確認してくれ」
プ「了解しました。」
以下、無限ループ
次回予告
近々これのちゃんとしたコードを書いてみようかなと。
続きはWebで！
