【読書会メモ】テスト駆動設計（1）

実施日時：2020/4/1
対象範囲：第1章
参加者：yodai、くめごん、まぶり、kassyi

まえがき
自動化されたコードが失敗したら新しいコードを書く
レッド・グリーン・リファクタリングを繰り返してTDDを実施する
テスト駆動開発はプログラムの不安をコントロールする手法
テスト駆動開発はテストが通ったらそこから先はコードが動作する事が分かるようになる。
セキュリティと並行性に関するプログラムタスクは、TDDで機械的に示せる所まで至っていない。
議論：
文体が回りくどい感じがする
はじめに
テスト駆動開発は大部分の一般的プログラマでも使える
2つのルール：コードを書く前に失敗する自動テストコードを必ず書く。
重複を除去する。
■第一部多国通貨
・まずテストを1つ書く
・全てのテストを実施して失敗を確認する
・小さな変更をする
・全てのテストを実施して全て成功する事を確認する
・リファクタリングを行って重複を除去する
第一章　仮実装
まずテストを書く事から始める
テストのエラー（コンパイルエラーも）を解消するためのクラスや機能を作っていく。
コンパイルエラーが解消したら、テストを走らせてレッドバーになることを確認する
最小限の変更（リテラルを直接代入するなど）を実施してグリーンバーを確認する
議論：
プロジェクト全体でなく、こっそり実施している人がいる程度。
テスト駆動開発は事前にテストコードを書く必要があるのでコストが増大する。
そのため、経営者側からは嫌われるのかも
DDDと組み合わせると、その場で結果が分かるのでお客さんに示すことが出来る。
プログラムの重複を取り除くとテストコードとプロダクトコードとの依存性も取り除かれる
変更のステップは細かくするべき、ステップが小さすぎるところまで来たらそれが適切な大きさとなる。
第二章　明白な実装
１．テストを書く（物語を書く）
２．バーがグリーンとなる様にテストを通す
　　汚いソースでも動ければ良い
３．正しくする
　　重複をなくしてリファクタリングする。
目指すのは動作する綺麗なコード
最初に動作するを目指して綺麗なソースコードに取り組む
テストを失敗した後、空実装してさっさとテストを通し、正しい実装をすぐに行ってテストを通した。
議論：
ある程度実装してからテストコードを書くのでも良いのかも
テストソースには、特定のソースにがっちり依存している場合が有り、他で流用する場合に失敗する事がある。
最初からテストコードを書くと依存関係の問題も解消されやすいと思われる。