【参加メモ】TDD Boot Camp 2020 Online #1 基調講演/ライブコーディング

t_wadaさんのライブコーディングがみれるというのでYouTubeLiveに参加しました! 聞きながら書いたメモを残しておきます。雑多です。

TDDのサイクル
Red,Green,Refactor を繰り返す

1. 次の目標を考える
2. その目標を示すテストを書く
3. そのテストを実行して失敗させる(Red)
4. 目的のコードを書く
5. 2で書いたテストを成功させる(Green)
6. テストが通るままでリファクタリングを行う(Refactor)
7. 1〜6を繰り返す

---

※私のぼんやりした認識では

1.失敗するテストを書く
2.コードを書く
3.テストを成功させる

の3ステップしかありませんでした( ̄▽ ̄;) 上記7つのステップをライブコーディングで詳細に説明されながら見ることができました。

---

進め方

頭の中で考えていることをdumpしていく
10項目あったとしたら、10項目に対してすべてテストを書いていくのではなく
徹底的に問題を小さく分解して倒すやり方

大きくは2つ
・一番大事そうなやつを選んで倒す
・テストしやすそうなやつを選んで倒す →最初はこっちがオススメ

1周目、2周目はやることが多い(設計している)ので重要なものを選んでしまうと重い
慣れてくると重要なものと簡単なものを一致させることができる
テストしやすい≠重要ではない

重要なものと簡単なもの、テストしやすいものとしにくいものの4象限

利用者の視点で、そのToDoができたらうれしい
テストファーストで組み込んでいく
テストを書いたら即失敗させる(=コードが実装されていないので)
予想通り失敗することを確かめたら実装モードに自分のモードを変更する
テストを成功させることに必要最小限なコードを書くことに全力を尽くす

Kent BeckはMartin Fowlerの定義を意図的に狭くした
「成功しているテストは成功しているままでコードをきれいに改善していくこと」
→「ソフトウェアの外部からみたふるまい」→あいまいな言葉
 テストが成功していればリファクタリングは成功している(=ゼロイチの世界)

早くRedからGreenにするためにコピペしたりなど汚いコードを書く
汚いコードをきれいにするのがリファクタリング

動作するコードをまず書いて、動作するままきれいにするのがテスト駆動開発

リファクタリングにもやめどきがある
1回のリファクタリングで深追いしなくて良い
何度もリファクタリングするチャンスはある

1周しただけでたくさんのフィードバックがある

テストコードから仕様を読み取れるようになってほしい

4Phase
// 準備 Arrange / Given
// 実行 Act / When
// 検証 Behavior / Then
// 後片付け ※GCがやってくれる

「何をやってるんだ?」と思われるだろうが、下から書く
検証がテストのゴールなので、軸をぶらさずにできる
単一の検証から書いていく

「数を文字列に変換する」ってどういうことだ?:
できると思っていたものが、あいまいなままだった(=手が止まるという残酷な瞬間)ということがわかる瞬間を前倒しにすればするほどPJが成功する
2000テストケースくらい書いてから間違いだったと気づくとダメージがでかい

コンパイルエラーもRedに数える
目の前のものがうまくいっていない=Red=設計の駆動力=予想通りの失敗=悪くない情報

実装してないのにテストを書く
つくる前につかうことによって、利用者側の視点で考えることができる

テストファーストの考え方:
つくりやすさとつかいやすさは一致しにくい
つかいやすい(読みやすい)コードの方が大事
つかいやすさはつかう側に立たないとわかりにくい
丁寧なドキュメントでつくりやすさを補ったりしがち

Q.問題(タスク)の分解の仕方はどうすればうまくなる?
A.「スキル」だといったが、テストの書きやすさを知る=経験するなので最初はできなくて良い
値のみやすさと考える
テスト容易性=観察のしやすさ コントロールのしやすさ
設計を学んでいく
最近だとクリーンアーキテクチャ
print=出力 から引き剥がす
経験から知るのと本を読んで議論から知ること
どちらもやると良い

E2Eテストなど動作が遅いテストについてはassertion1つの原則を破っても良い

ひどいコードを書く代わりにリファクタリングへの挑戦権を得る

テストを増やすのは簡単だが、消すのは書いた本人しかできない
「テストにはメンテナンスコストがかかる」という認識が黎明期(=18年前)にはなかった
理解容易性が低いテストコードほどガンになりやすい
読みにくいテストコード=企業の不良資産

将来の自分自身にもなる
仕様は1ヶ月もすると頭の中からいなくなる
頭の中に残っているうちにテストの構造化とリファクタリングまでやらないと後々の不良資産になる

---

メモは以上です。太字は必ずしも見出しではなくt_wadaさんの発言で気に入っている部分です。記憶消して(←消すな)もう一度最初から参加したい気持ちになるイベントでした。とても良かったです!


この記事が気に入ったらサポートをしてみませんか?