渋日記@shibu.jp

実行結果を記録して、過去の実行結果と比較する機能をPySpecに組み込みました。0.53のリリースはまだ先ですが、codeplexのPySpecのページのソースコードのところからダウンロードできます。ドキュメントは、テストコードと、サンプルコードのみですけど。

レガシーコードのテストといっても、実際はレガシーコードを改修したり、機能追加したりする、というストーリーで考えています。

少し、この記録テスト機能を使ってみた感覚から、テストのステップを考えてみました。ちなみに、記録機能は、メソッドの入力、出力を記録するかどうかを変更できます。また、プロキシとして動作し、オブジェクトのメソッド呼び出しを記録する機能に関して、今は全部のメソッド呼び出しを記録しますが、正規表現か、配列かをつかって、メソッド記録のフィルタリングは実装しようかな、と思います。

案ばっかり出てなかなか進まないけど

• HTMLドキュメント生成機能をコンソール版にもつける
• MockObjectの機能強化。with_any_argumentsとかね。呼び出し回数を柔軟に設定できるように、とか。
• GUIテスト対応
• WSGI対応して、ウェブアプリのテスト機能対応。

簡単なMockあたりはヒマなときにさくっと終わっちゃいそうだけどね。HTMLはどうしようかなぁ。

英語チュートリアルを作成中。チュートリアルを作成していると、「あぁ、こういう機能も欲しいね」と思いつきます。自然言語を書くのも貴重なインスピレーションの元ですね。開発前のソフトウェアが形になっていないときの仕様書なんて、いくら書いても地に足が着かない状態だので効率は良くないとは思いますけどね。

今のところ考えているBDDの手順は以下の通り。

1. 仕様を自然言語で書いてみる
2. 仕様をpyspecを使って表現してみる
3. pyspecを実行してみる→失敗
4. pyspecが通るようにコードを書いてみる→パス
5. 製品コードをリファクタリング→テスト
6. 仕様コードをリファクタリング→テスト

基本はTDD。フィードバック回数、頻度が高ければ高いほどいいけど、そこはもうTDDでやり尽くされている領域なので、あえてそこを離れる必要はないしね。TDDとの違いで言えば、コンテキストと仕様を明確に分ける、ということ。最後に、仕様コードもリファクタリングしてから終わるということ。本当はHTMLでドキュメントが生成できれば、最後の段階でマニュアルもできるので、もうちょっと良くなると思うけど。

pyspec。地味にバージョンアップ中。でも公開場所がないので。自分のマシンの中だけ。codeplexにでも場所を作ろうかな。現在のバージョンは0.50。

今日はpyspecにユーティリティクラスを追加。デリゲータなんだけど、複数のオブジェクトにメッセージをブロードキャストできるの。これで TestResultを複数登録できるようにする予定。コンソールに出しつつHTMLを出力する、とかね。HTML出力を作らないと。

Design by Contractの基本仕様は完成。場合によってはpyspecから切り離して、単独でも使用する可能性があるので、コアは小さく。後は、このメソッドの実行結果を拾って、レポート出力ができれば動く仕様書にまた一歩近づくかもね。

オブジェクト倶楽部で侍RedさんのRejectTalksを聞いて閃いたpyspec拡張。About(XX). should_not_change()。一度目に実行したときの結果を覚えておいて、二度目以降はそれと比較するの。大規模レガシーシステムのテストを手早く作る時専用の非推奨機能。あの資料もう一度見てみたいなぁ。その前に自分の資料も公開しないと。

うっかり注文してしまいました。しかも洋書。xUnit Test Patterns(洋書で全880ページ)もまだ読んでないのに。でも、xUnit Test Patternsは僕が考えていることはいくつか書かれてないですね。DbCとの連携とかね。どっかには別の言い方で書かれているのかもしれないけどね。

Implementation Patterns (Addison-Wesley Signature)

• 作者: Kent Beck
• 出版社/メーカー: Addison-Wesley Pub (Sd)
• 発売日: 2007/11/15
• メディア: ペーパーバック

xUnit Test Patterns: Refactoring Test Code (Addison Wesley Signature Series)

• 作者: Gerard Meszaros
• 出版社/メーカー: Prentice Hall
• 発売日: 2007/05/11
• メディア: ハードカバー

テストコードはどうしても外部からのテストだし、モックオブジェクトも、内部に取り込まれた外部(わかりにくい日本語だけど)のテストにしかなりません。そういう意味で真のホワイトボックステストはをするにはDbC。次にテスト駆動開発で来るムーブメントかな、と思います。ひょっとしたら、この前の形式仕様言語の話を聞いてただ興奮しているだけかもしれません。

プログラマの視点からユーザの視点へのシフトとしてビヘイビア駆動開発。データベースやネットワークなどのドメインごとのテスト。テストのムーブメントのベクトルがなんとなく見えてきた気がする。ビヘイビア駆動開発を真にユーザ視点にできるか、DbCで真のホワイトボックステストを組み込むことができるか？このあたりが2008年前半のチャレンジかな。

僕はテストは楽しくて書いているだけなので、別に工学的な意味を求めて書いている訳じゃないです。電化製品をバラして愉しんでいる子供と一緒。ソースコードをバラす道具で遊んでいるだけだもんね。ま、それでできたシステムをユーザが喜んで使ってくれるわけだから、仕事になっているわけだけど。