2008年02月20日

「レガシーコードのテストのお作法」

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

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

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

続きを読む
posted by @shibukawa at 00:00 | Comment(210) | TrackBack(0) | BDD はてなブックマーク - 「レガシーコードのテストのお作法」

2008年02月15日

「TDD/BDDは不完全な単体テストを誘導する?」

TDD/BDDは不完全な単体テストを誘導するという記事が出ています。要点としては、TDD/BDDは、特定のケースの検証をしているにすぎず、アプリケーション内部で発生しうる、すべてのケースの検証をしているわけじゃない、ということです。まぁ、考えてみれば当たり前なんですけどね。

続きを読む
posted by @shibukawa at 00:00 | Comment(84) | TrackBack(0) | BDD はてなブックマーク - 「TDD/BDDは不完全な単体テストを誘導する?」

2008年01月13日

「PySpec機能拡張案」

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

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

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

posted by @shibukawa at 00:00 | Comment(179) | TrackBack(0) | BDD はてなブックマーク - 「PySpec機能拡張案」

「英語チュートリアル」

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

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

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

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

posted by @shibukawa at 00:00 | Comment(197) | TrackBack(0) | BDD はてなブックマーク - 「英語チュートリアル」

2007年12月27日

「PySpecバージョンアップ」

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

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

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

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

posted by @shibukawa at 00:00 | Comment(71) | TrackBack(0) | BDD はてなブックマーク - 「PySpecバージョンアップ」

2007年12月25日

「僕とBDDのつきあい方」

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

Implementation Patterns (Addison-Wesley Signature)

Implementation Patterns (Addison-Wesley Signature)

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

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

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

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

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

posted by @shibukawa at 00:00 | Comment(187) | TrackBack(0) | BDD はてなブックマーク - 「僕とBDDのつきあい方」
検索ボックス

Twitter

www.flickr.com
This is a Flickr badge showing public photos and videos from shibukawa.yoshiki. Make your own badge here.
<< 2016年12月 >>
        1 2 3
4 5 6 7 8 9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29 30 31
最近の記事
カテゴリ
過去ログ
Powered by さくらのブログ