櫓日誌

<< 自動化 | main | RSpecの拡張 >>
スポンサーサイト

一定期間更新がないため広告を表示しています

| スポンサードリンク | - | | - | - |
RSpec
自動化ツールを作成・改良する間、RSpecで仕様を追加・修正したので、テスト駆動ではなく振る舞い駆動で考えるということがどういうことか、少しわかってきた。

振る舞い駆動とは言っても、やっていることはテスト駆動のときと変わらない。今回は以下のような流れでツールを作った。
基本的な仕様を記述(RSpec)→動くモデル(Rubyのクラス群)を作成→仕様通りか検証(RSpecを適用)→仕様を拡張(RSpecを追記)
→モデルを拡張→仕様通りか検証→モデルを単純化→仕様通りか検証→仕様を拡張→・・・

XUnitとの違いとしては、XUnitではテストケースを記述していたのが、RSpecでは、contextとspecifyを使って仕様を記述する。contextとspecifyの関係は契約による設計の事前条件と事後条件の関係に近いかもしれない。contextがクラスなどのモジュールの状態を表し、specifyがある状態において満たさなければならない振る舞い仕様を表しているようにも見えるので。I/Fに着目するか、状態に着目するかの違いなのかもしれない。

ただ、その他にはさほど大きな違いを感じなかった。最初は、テスト仕様と考えないようになったことで、プログラムの内部仕様(ホワイトボックス視点)ではなく、外部仕様(ブラックボックス視点)に集中するようになるかと思ったけど、自分の場合はそうはならなかった。完全にブラックボックス視点にするとたくさんの仕様を書かないといけなかったので、結局はホワイトボックス視点が必要に・・・

他にも、RSpecは仕様というよりは具体例の集合(たとえば、入力が奇数の場合1、偶数の場合0を返すという仕様ではなく、入力が1のとき1を返せ、2のとき0を返せということを記述する)なのでどのような具体例を記述すべきかとか(仕様というよりはテスト的な考え方?)、イテレーティブに開発する場合、どこまでを基本仕様と考えるべきかとか、考えたいことはいろいろあるけど、風邪気味なのでそれはまた別の機会に。。
| YAGURA | - | 00:22 | comments(0) | trackbacks(0) |
スポンサーサイト
| スポンサードリンク | - | 00:22 | - | - |









http://yaglog.jugem.jp/trackback/33
    123
45678910
11121314151617
18192021222324
252627282930 
<< June 2017 >>

このページの先頭へ