TDD Boot Camp 北陸 - rfなブログ

TDD Boot Camp 北陸に参加してきました！

初日

〜開始

5時半に実家を出て名古屋へ。
名古屋で id:bleis-tift と合流してと小松まで。
新幹線の英語アナウンスはレイハさんらしい。
小松からは wtnabe さんの車で現地へ。
雪が残ってたりして驚くなど。

t-wadaさんの講演

メモ晒し。

テスト駆動開発とは何か
テスト：
　Developer Testing (開発者の開発促進)
　Customer Testing (顧客・マネージャの進捗管理)
　QA Testing (品質保証担当者の品質保証)
TDDの対象：Developer Testing

Developer Testing :
　プログラマのプログラマによるプログラマのための
　プログラムとしてのテスト

三本柱 :
　バージョン管理、テスティング、自動化(自働化：何かおかしなことがあったときのみ通知)

Developer Testing の最大の利点：
　動くことに自信が持てる

TDDのサイクル：
　テストを書く
　実行し失敗させる (Red)
　テストを通るコードを書く (Green)
　テストが通るままでリファクタリングを行う (Refactoring)
　以上を、小さいイテレーションで回していく
　：黄金の回転 (Red → Green → Refactoring)

TDDのこころ：
　一つずつ、少しずつ
　複数を相手にしない。一つずつ対処する
　　(TDDに限らず、仕事でも)
　　分割の仕方は慣れ
　すばやくまわす
　　素早く回せる位に小さく分割
　自分が最初のユーザ
　　自分が書くコードの最初のユーザは自分
　　使いにくいところに自分が最初に気付く
　不安をテストにする
　　自分が不安に思ったところにテストを書いて、安心を得る
　祈るのではダメ、安心して飛び込む
　　テストがセーフティーネット
　TDDはテスト技法ではなく設計技法
　TDDにおいて、テストは目的ではなく手段

TDDの真の目的：
　健康
　　変化に対応するのは健康体のコード
　　　無駄のないコードを作っていく
　　　一つの変化に対して修正点が一カ所
　　変化に対応するのは健康体のチーム
　　　チームに自信を持たせる
　不安を克服して、健康体を目指す

創発的設計
　フィードバック、学びを否定しない
　計画し続ける、設計し続ける
　TDDは創発的設計の手段の一つ

テストファースト
　アサートファースト
仮実装
　テストのテスト
間合いを計る

コードと一緒にテストを書く
　プロとしての嗜み

ペアプロセッション1

田中さん (@tanahizu) と。

メモ晒し。

お題：
文字列フィルタ

1テストメソッド1アサート
パラメタライズドテスト

パラメタライズドテストまでいった。
Javaのパラメタライズドテスト微妙。
C#のパラメタライズドテスト素敵。

ペアプロセッション2

三宅さんと。

メモ晒し。

仕様変更
1. NGワード複数可能、後から変更可能
2. <censored> を変更可能に
3. ユーザ名はフィルタに引っかからないように
4. 入出力を抽象化して
5. 統計を取る (何が・誰が何回引っかかったか)

3まで出来た。
NGワード複数個対応で、複数個を基準に書き換えて、単数でも1要素の集合とすることに。
単数の実装があるんだから、複数個はそれ回せば良かったと後で思った。

研修後〜夕食

この辺ではよくバグ(カメムシ)が出るらしく、部屋にはデバッガ(ガムテープ)が。
夕食の場で自己紹介。やっぱり学生に見えない俺・・・

深夜

隣の部屋でJavaやったりとか、研修室で飲んだり食べたりpython教えてもらったりとかしてた。
Redmine便利そう。バージョン管理 + チケット管理 + CI はやっぱりいいなー。
この辺既にやってるところで働きたいと思うが、あんまり無いのかなぁ。
結局、3時半位まで研修室にいて、その後寝た。
結局部屋にバグは発生しなかった。よかった。

2日目

午前セッション

レガシーコードに対してテストを書きながら修正していく。
メモ晒し。

例：IokeBot (katzchang さんの)

レガシーコードを修正する際は必ずバージョン管理を行う
　git便利

キャラクタライゼーションテスト (仕様化テスト)
現在のコードに対してテストを書く
　修正を行っても現在の動作を壊さないか

1. インスタンス化出来るか
2. 現行のメソッドのテスト (可能なら)
3. 内部構造のテスト
　依存を切っていき、内部構造のテストを容易にする
　　依存を切る/外部から注入できるようにする ことで、テスト可能にする
　気になる(テストしたい)部分をメソッドに抽出 (必要なら)
　フィールドを追加して、値の変化を外から確認出来るようにする (後で除去する)

外部のライブラリを使う場合、使い方を学習する時点でテストを書いておく (学習テスト)
ライブラリの仕様が変わったときに容易に検出できる

変化の激しいライブラリと自分のコードを抽象化等で分離する
　間にインタフェースをかませる 等

壊したことに気付く仕組みが大事
普通ペアで作業

午後セッション

Java組は id:Nagise さんのリバーシを題材に。
構造を追うのに時間がかかってた。

構造を追うために、とりあえずインスタンス化のテストを書いたけど(書いたのは自分)、目的によっては書かなくても良かったのか？
多分目的のテストを書くときにインスタンス化はする必要あると思うからやっぱり必要だったのかな。

インスタンス化のテストとAIがの手番のテストを書いた。
リファクタリングして内部要素(白の数と黒の数)が取得できるようにして、AIの手番で白の数と黒の数が変わるテストを書いた。
次に自分の手番のテストを書いていたら、リバーシのルールでおける場所(ひっくり返すことが出来る場所)
しか置くことが出来ないことが分かり、どこに置けるか調べていたところで時間切れ。

GUIとかが絡んでて、ロジックと結びついてるとテストしにくい。
レガシーコードのテストを書く場合も、徐々にGUI等とロジックを分離していき、分離したテスト可用な部分のテストを書いていく感じかな。

感想

とても楽しく、勉強になりました。
id:katzchang さん、id:t-wada さん、参加されたみなさん、ありがとうございました！