TDDBC 2018
リンク
ペアプロで使ったソース
TDDとは
書籍 テスト駆動開発
テストを最初に書き、実装を進めていく手法
実装していない関数を使うため、呼びやすく使いやすい関数を定義できる。
つまり関数名と引数を決めてから実装するため、使うことを主とした実装ができる。
方法
〇設計
1. 目標を考える(設計)
2. その目標を示すテストを書く
3. テストを失敗させる(RED)
4. 目的のコードを書く
5. テストを成功させる(GREEN)
6. テストが通るまでリファクタリングを行う(Refactor)
7. 1~6を繰り返す
一気に書くのではなく、少しずつ増やしていく(ひとつずつテストを通していく)
簡単で小さなコードから書いていく
※リファクタリング=コードが動作するままできれいなコードにしていく
やろうと思えば無限に出来る
時間でリファクタリングをやめる
基本重複を除去する
〇テスト
1. 前準備
2. 検証
3. 実行
assertの引数であるexpectedとactualの順番はフレームワークによって違うためちゃんと確認
通る値をreturnしてみる(テストコードのテストをする)
通らなければテストコードにバグがある
関数を書く前にまず使う(テストする)=>理想の使い方をまず書くことで使いやすく作ることが出来る
検証を先に書く
ゴールが分かりコードを書きやすい
テストが書きにくいことに気づく=>より簡単なTODOに書き直す
ひとつのテスト関数に複数のアサーションを書かないようにする(できるなら1関数に1アサーションだけ書く)
ポイント
やろうとしていることをTODOとして書き出す(1)
やることを細かく分解していく
testファイルを作ったらまず失敗させる
うまく失敗させられなかったらTest出来る状態が整っていない
テストは日本語で書いていく
何をしたいのかが分かりやすい
→テストコードはドキュメントになる
ex) func _1を渡すと文字列1を返す() / func _5を渡すと文字列Buzzに変換する() etc...
入れ子構造にしてTODOのメモと同じような形に落としていく
テストがレッドのときはリファクタリングしてはいけない
簡単な値を返してとりあえずグリーンにする
テストフレームワークはテストの独立性を保つため上から実行されず、ランダムで実行されるように設計されていることがある
テストに依存関係が発生しないようにする
2~3箇所重複したらリファクタリングする
前準備のメソッドは用意されているはず
FizzBuzz(このメモの形でテストクラスを作っていく)
FizzBuzz数を扱うクラス
□文字列に変換する
□1を渡すと文字列1を返す -> 仮実装
□2を渡すと文字列2を返す -> 三角測量 -> 実装
第三者から見ても分かるように増やしてもよいが、出来るだけ少なくしてもよい(分かりやすい形にする)
変にテストコードを増やして意味ありげだが意味がないコードが残らないようにする
□3の倍数のときの変わりにFizzに変換する
□3を渡すと文字列Fizzに変換する -> 仮実装 -> 本実装
□5の倍数のときの変わりにBuzzに変換する
□5を渡すと文字列Buzzに変換する -> 明白な実装
□3と5の両方の倍数の場合はFizzBuzzに変換する
※石橋をたたいて渡る実装・明白な実装がある
まとめ
問題を小さく分割
歩幅を小さく(実装の方法を考える)
実践(ペアプロ)
git
branchは変更の大枠のくくり
ccommitは-amでファイルの変更分をコミットしてくれる
go
まずはインスタンスを作成する関数を作る
インスタンスを元にレシーバを受け取る関数を作る
レシーバの基準はそのインスタンスに関係するもの
errのif文を何よりも最初に書く
エラー文はできるだけわかりやすく書く。
期待値と実際値は何なのかを書く。
if文ではelse極力使わない。elseがあることでその後に何もないと考えてしまう。