20190227-tdd-workshop.md

gistfile1.txt

■テストモジュール選定時は、下記を出来るようにしたいなぁ。。
パラメタライズテスト
Nestedテスト

■気になった点

・動く仕様書としてテストコードを書く
・テスト実行結果だけを見て、仕様書として正しいか？確認できること
・パラメタライズドテストいいよ
・TODOリストとテストクラスの構造が似通うというか、同じこと





・四冊の一個
・Qiitaの記事一覧
・フォント何を使っているんだろう？




ピアソンショック
4冊

達人
リファクタリング
TDD
？？？


必要十分な設計を必要なタイミングでやる。JITてきな。

TODOリストのやる順番
もっとも重要 or もっとも簡単

最初は他にやることも多いのでもっとも簡単を選ぶと良い。

リファクタリングの脱出条件
時間で区切る or linterによる条件や重複数を一か所にするなど

FizzBuzzはアメリカの事業会社で、ホワイトボードテストでプレッシャーのせいか、１割しかとけなかった。
　　ブログかなんかのエントリーから一躍有名になった

問題解決の基本
　要素分解と各個撃破

コアのロジックが無ければ、目視で構わないですよね。

４フェイズテスト
　　前準備、実行、検証、後片付け

３フェイズ ３Aと呼ばれる
　　前準備、実行、検証
　　After, action, assertion

自動テストの引数の順番
　　期待値、テスト値

Actualって書いていこう。resultやめる！！


作りやすいコードよりも、使いやすいコード！！


環境を疑う前に自分を疑え！！

欠陥挿入。ミューテーションテスティング

■歩幅の大きさを変えていく
仮実装　return "1"とかね
三角測量　ちゃんとした実装にする。String.valueOf(num)とかね
実装
明白な実装

リファクタリングは、実装コードから。そのご、テストコード。

動作の遅いテストでは、Assertionを複数書くのもあり。
　弱点を理解しておくこと。
　　assertionRoullet
　　テストこけたときに一瞬で分からない。

３アウトの場合
　Undoパターン（３のテストを消しちゃうとかね）
　仮実装にするパターン

テストコードから標準出力に出すのはご法度。

テスト実行時の並列性をあげたいが、依存関係があると遅くなってしまう。

レッドバーを見ないように、うまいことリファクタリングしていく方法もあるよ。

テストコードを動く仕様書にしたい
　TODOリストをそのままテストの構造とする
　テストの実行結果をTODOリストと同じにする！！
　プログラムはASTツリーだから、それっぽくテストもツリー化して書けるよ。

意味がありそうだけど、意味がないものをメンテの邪魔になる。

ペアプログラミングのドライバーとナビゲータは、WRCから来ている

交代タイミングは、5分だと短すぎて、10分だと長すぎる
7-8分、で交代が良さそう。



テストレビューの時は、最終出力が気になる形。表記ゆれが無いか？テスト内容がしっかりしているか？

含む、含まないは、４ケースが基本


テストの説明は、抽象的なのから中に行くにしたがって、具体的になっていくのが良い。
　迷ったら、抽象的なほうにしておく。あとから見たとき分かりやすいし。

パラメタライズテストの話。

・レガシーコード改善ガイド
　　stack over flowで一番多い。

・レガシーソフトウェア改善ガイド

・ソフトウェアテスト入門

・ソフトウェアテスト技法ドリル

ぴあわいずほう
直行ほう

・実践テスト駆動開発