テスト駆動開発
https://scrapbox.io/files/6880e9ee03cba50100657923.jpg
この本を読むまでの自分が思ってたこと と 読んでから(->)
-> そもそも TDD は自動テストのことに限らない
自動テストはだるい
テストケースを作るのがだるい
-> だるいはそうだが、テストに拠って書くので目的がはっきりする
作っていくうちに関数の機能・名前を変えると自動テストのコードも書き直す必要がある
-> そう。レッド、グリーン、リファクタ の流れなのだから
-> リファクタも自信を持って行える
自動テストをしなくても、3個程度の標準的な入力と思いつく限りの例外的な入力を試せばだいたい動く
ゆえに、小規模プロジェクトではそんなに必要ない
-> ほんとうにそうか？いままで自分がやってきたことはそんなことなかったぞ
-> 大きすぎる一歩とも見れる
ここからは本の内容
テストを考えるのは良い抽象化を考えるのと同じくらい難しい 何はともあれ、テストを書け
テストから書け
一歩ずつ進もう
コードは罪を犯してもいいから、書け
重複の削除は後で良い
テストすればいい
正しい歩幅はないが、不安なら歩幅を小さくできる
コードが正しく動作する自信はテストがくれる
休憩とは対極の考え方がある。困難な状況に直面しているときは、とにかくどんどん推し進めて、強引に切り抜けるしかないこともある。しかし、プログラミング文化はマッチョ精神ーー健康や家族、ときには自分の命さえも犠牲にしてやりとげること――に毒されすぎている。そうなってしまうと、もう何も言えることはない。カフェイン中毒を自覚しても進捗が芳しくないならば、もう頻繁に休想は取れないかもしれない。でもまずは、散歩をしよう。 個人開発は作業の途中でもうわかるから実装できる、ってとこで切ったほうがいい
次始める時の hook になる
todo を書いて終わる
テストを書いて終わる
罪を犯したまま終わる
チーム開発は完成させてから終わる
チームメイトはコードが途中であることを知らない
スケジュール、タスクを管理する人がいる
負のフィードバック
重圧がかかるとテストの実行がおろそかになる
テストの実行がおろそかになると欠陥が増える
欠陥が増えると重圧がかかる
はまってしまったときはテストを通して自信を回復しよう
TDD はテストを先に書くことではない
リスト
レッド
グリーン
リファクタ