読者です 読者をやめる 読者になる 読者になる

tanaka51のブログ

http://blog.tanaka51.jp に移転しました

第2回 The RSpec Book 読書会をやっていました

勉強会

実は、3/12 に The RSpec Book 読書会をやっていました。
もう2週間以上たってしまったけれども、記録を残しておきます。

今回やったのは、"Chapter 3 フィーチャを表現する" です。
この章からしばらく、"Codebreaker" という CUI のゲームをつくっていきます。
Codebreaker の作成を通して、BDD によるアジャイル開発を学べるようになっています。

Codebreaker のルールです。

  • プレイヤーは、コードブレーカーである
  • コードブレーカーは、コードメーカーによって作成された暗号を解くのが目標
  • コードメーカーは、1〜6までの4つの数字で暗号を作成する
  • コードブレーカーは、暗号を解く機会を何回か与えられる
  • コードブレーカーは、4つの数字(1〜6)を推測する
  • コードメーカーは、推測された数字に対して評価し、記号を返す
  • 推測された数字の1つが、場所・数字共にあっていれば + 記号
  • 推測された数字の1つが、数字のみあっていれば - 記号
  • + 記号は必ず - 記号の前に存在する
  • 暗号が 1234 で、推測が 4256 である場合、評価は +- となる

さっそくプロジェクトを開始します。

リリース計画

  • BDD の3大原則の1つ、「十分といったらもう十分」
  • ユーザーストーリー
  • ユーザーストーリーは、「役割+アクション」で表現する
  • 役割に焦点をあわせる
  • ユーザーストーリーから絞り込むには、コンテキストを考慮する
  • ユーザーストーリーは計画ツール
    • ビジネス価値がある
    • テストが可能
    • 1つのイテレーションで実装できるほど小さい

作成されたストーリーから、最初のリリースプランを絞り込みます。
次は、これをイテレーションに分解します。

最初のイテレーション計画

  • ATDP(Acceptance Test-Driven Planning)
  • ATDD(Acceptance Test-Driven Development)
  • ATDP は ATDD の拡張であり、その違いは受け入れテストを書くタイミングが決まっているかいないか
  • Cucumber でフィーチャを表現し、アプリケーションとやりとりする
  • Cucumber でのフィーチャは、タイトル、ナラティブ(narrative-物語)、シナリオの3つで構成される
  • タイトルはフィーチャが誰を対象とし、何に関するフィーチャなのかが分かるように書く
  • ナラティブは、システムが何をしたいかを、主に Connextra フォーマットで書く
  • シナリオは、フィーチャの受け入れ条件をかく
  • Cucumber には "シナリオアウトライン" という機能があり、フィーチャとシナリオを DRY に保てる

読みつつ写経しつつ…

第3章はここで終了です。
Cucumber でフィーチャを表現しただけです。
次章から Ruby のコードが出てくる…と思います。

次回は 4/2(月)に 20:00〜 株式会社万葉のオフィスでやります。
次は第4章をやる予定です。

The RSpec Book (Professional Ruby Series)

The RSpec Book (Professional Ruby Series)