PySpec3について - shibu

そろそろberryMQも実装が落ち着いてきているので(マルチスレッドのロックとか、アマアマな部分はたくさんあると思うけど)、pySpec3も考え始めようかな、と思っているところです。

berryMQはもともとPySpecのリライトのためのバックエンドとして作り始めたのだけど、その後に知って、現在絶賛猛プッシュ中のSphinxに出会ってからはちょっと別路線を考え中。Cucumberみたいなのも面白そうだしね。あと、pyspecは記号が多くて、シフトキーで指が疲れるという問題もあるので。ということでSphinx拡張＆ビルダーとして実装する方向で検討中。TDD→BDDはドキュメント化の流れなので、いっそのこと、ドキュメントに埋め込んでしまう方が潔いはず。とちぎRuby会議02では「文芸的テスト」と言っていたけど。

Sphinx拡張は、htmlやlatex、pdfの場合には整形してテスト仕様書として出力し、pyspecという名前のビルダーだったら、構築後のイベントを拾って、中のテストを全部たどって実行・・・という流れかな。普通にUnitTest的に実装していたpyspec2までは、before, specは関数として個別に実行していたけど、くっつけたコードを作ってevalしてやればいいか。エラーの見せ方とかは工夫が必要かな。

BDD的なサンプル

.. pyspec::

   .. before:: 空のスタック

      empty_stack = Stack()

   .. spec:: 空かどうか判断できる

      empty_stack.empty() should be True

cucumber的なサンプル

.. feature:: ログインページ

   :when: ログインページを表示して
   :and: フォームのユーザ名に"test", パスワードに"testpass"と入れて送信ボタンを押すと
   :then: ログインに成功する

最近悩んでいるのが、テストコードがシンプルになるように強制するかどうか。たとえば、ユニットテストのフレームワーク上で、
ちょっとの行数しか書きたくなくならないような、文法にしてもいいけど、あまり強制しすぎて、テストのためのアダプターコードが増え過ぎちゃうと、逆に仕様変更に弱いコードになりそうな気もするし。適度に無駄は必要なんだろうな、と思っているところ。