TDDBC大阪3.0外伝 参加しました!


2013年はじめのTDD Boot Camp in 大阪 外伝
開催日:2013年01月13日

午前は講演、午後は演習(ペアプロ)の2段構成でした。 10時から18時までと長丁場でしたが本当に楽しかったし、周りの皆さんと色々話もできてモチベーションが上がった!!


午前の講演時のメモ

いろふさん(@irof)、渡辺さん(@shuji_w6e : 資料)のお話を聞きました!

テストの価値は失敗することにある.

  • テストを失敗させる
    • 失敗するバグを埋め込む
      ちゃんと失敗してくれる、 失敗は最小、 失敗をわかりやすく

  • 他人の書いたテストはわかりづらい
    • テストはわかりづらいだから当たり前にしよう
    • 特別なことを当たり前にする

あたりまえのこと(特別なことはない)

  • テストは落ちるもの
  • テストは読みにくいもの

TDDは開発手法

良いプログラムは開発できるが、良いシステムを開発できるわけじゃない。
TDDはテストリストが起点
良いシステム = 顧客の求めるシステム

「何を構築するか?」を考える
顧客の言葉を使ったシステムの使い方
ユースケースユーザストーリ
システムの外部的な振る舞い

ユースケース駆動開発

ユースケースを開発の起点として定義する。

  • システムとユーザインタラクションを記述
  • 一行で一つのアクション
  • 〜すると記述(できるは避ける)

外部設計 => システムを外から見た時の利用者視点

ユースケースから実装を導く

  • ロバストネス分析
    バウンダリ
    コントローラ
    エンティティ

ユースケース中の名詞 -> ドメイン として定義
ユースケース中の動詞 -> メソッド として定義

抽象的なユースケースのシナリオから、具体的な例として変更する => 具体的な値を入れることでユースケースから受け入れテスト(機能テスト)を導く事ができる。ユースケースを用いることでシステム全体を設計する

(例)自動販売機にお金を入れる => 自動販売機に100円入れる


午後の演習

@oota_kenさんと@kyon_mmさんとペアを組ませて頂きました。Groovyを触ってコツを掴んだ気がします。新しい言語でコードを書くときはいつもプログラミングは楽しいなーと感じます。
そして、GroovyとSpockはホントテストが簡潔に書けると実感。これは覚えるべきだなと思いました!!

演習の時のコードをアップしてもらいました。TDDBC Osaka Groovy

和田さんのペアプロでのレビュー

パラレルチェンジ(でかいリファクタリングの時に有効となる方法)でリファクタリングをした。
パラレルチェンジとは(參考

変更箇所が多数ある場合に、リファクタリング前のコードとリファクタリング後のコードを同居させ、1箇所ずつ変更するごとにテストコードで確認しながらリファクタリング後のコードへ移行させていく。

演習中でのパラレルチェンジをする流れ
・お金の扱いをInteger から Moneyクラスにする
・メソッドオーバーロード
・Integerで扱うところをなくしてMoneyを使うことにする

余談(イベント中で印象に残ったこと)

@kyon_mmさんと何気なく話していた時に話していた内容がとても刺激をうけた!!!!

「(@kyon_mm)今日は4時間で20数コミットかー、普段は60コミットくらいはしているけどなー」・・・
なんだって!!!コミット数が全てを物語っていると思う。自分は短時間でこんなにコードに変更を加えた経験はないし、いったとしても4時間で20コミットまで行くか行かないかだと思う。。。こういう所が差なんだろうなーと。

これからは技術書を読むことに加えて、もっとコードに戯れて楽しんでいけるようにしたいなー!!
いろんなコードをコミットしまくれる1年にしたい!

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です