！は読みながら、思い出したこと、考えたこと、疑問など
第一部
仮実装
TodoListを書く
途中で思いついたものも、書き留めて、一つのことに集中してできる。
明白な実装
TDD cycle
・テストを書く
・動かす
・正しくする
！この本を薦めてくれた人は、何故かこれで開発をしたいといているのにもかかわらず、プロセスにTDDサイクルを組み込んだものをガン無視して進める。どうしたらいいんだろう。
三角測量
シンプルな実装で、すぐにリファクタリングではなく、もう一つテストを書く
２つのテストを同時に通るリファクタリングをする。
！どのフェーズでも常にテストファースト
意図を語るテスト
！コードともに同じテストでも意図が変わってくる。だから、テストもコードともにリファクタリングが必要てこと？？
原則をあえて破るとき
テスト不足に気づいたら
！うむって感じ。
疑念をテストに翻訳する
メソッドの重複の除去の一歩近づくためにメソッドのシグニチャを合わせる
（メソッド名や引数の型と順番、戻り値の型を統一する）
メソッドの宣言を親クラスに移す
実装を隠す
大きめの設計変更ではなく、手前にある小さな変更を
同じ修正をするときは大胆に近づけ、共通部品にできるように準備
全く同じなコンストラクタは親クラスに引き上げ
歩幅の調整
テストに聞いてみる
不要になったら消す
テストも助長になったら消す
設計とメタファー
機能のためのメタファーについて深く考える
新しいメタファーでテストを書く。
コードを直してテストを通す。
！深くってどのくらい？どこまで？？
実装を導くテスト
学習用テストと回帰テスト
テスト任せとコンパイラ任せ
将来の読み手を考えたテスト
うむって感じ。
##第２部xUnit
前準備
後片付け
数え上げ
失敗の扱い
スイートにまとめる
！開発しているコードでは、量が多くて、一部分をやるには、どうしたらいいか…
！今度ツール作るときはテストも一緒に書くをやってみたい。（C#どうやって？？？）
XUnitの全体振り返り
新しいプログラミング言語に触るときには、まずxUnitを実装してみる。
！積本を読み切ったら、新しい言語を月に１個触れるのをやりたい。
https://survey.stackoverflow.co/2025/technology?utm_source=chatgpt.com
第３部テスト駆動開発のパターン
テスト駆動開発のパターン
！大きなコードを部分的に持ってきて、テストするしかなさそう
テストが互いに独立しているなら、実行順序に依存しなくなる
！うちの自動試験の内部の一つ一つの命令は独立してない。１つのテストケースでみると独立していそう。けど、小さく確認できていないから、微妙な気がする…
！テストファーストにできているのか？Q&Aで足りてる？
アサートファーストとは、こうなってほしい！という結果の部分（アサート）を書くことから始めること。つまり、期待する結果を書く
！できてそう。
！テストデータは、なるだけリアルに近いほどいい？妥協したくなるのはなんで？？
コードにマジックナンバーを書くな
ー＞コードの中に直接意味不明な定数値をベタ書きをするなと言う意味。
レッドバーのパターン
・説明的なテスト：！いまいちわからなかった
・学習用テスト：！画像処理でやりたい。ChatGPT教えてくれた。参考にする、
新機能のとき、まずテストを書いてみる！！！
テスティングのパターン
グリーンバーのパターン：もう１回
フィクスチャーとは、テストを実行するための前提条件（データや環境など）
xUnitのパターン
デザインパターン：もう１回
NullObject：！たくさんのNullチェックあるな。どうにかしたくなってきた。
PoggableObject：同じ条件の分岐を２回見たら使うといい。！やりたいー
PluggableSelector
リファクタリング
！できてることも大半。できてないとも言い切れないところが、ある。
TDDを身につける
不安が退屈に変わるまでテストを書く
！最近テストを書いてて、その時最後の方には飽きていたから、ちょうどよかったのかも
ポリモーフィズムとは、同じ呼び出してもObjectの方によって振る舞いが変わる性質。
将来のことを考えずにコードを書くことが将来そのコードが状態に適応する可能性を広げる
インクリメンタルな設計：必要に応じて少しずつ設計、実装を追加
BDD（Behavior Drive Development）
BDDをするときに使用するCucumber：自然言語でテストシナリオが書けるフレームワーク
＜メリット＞
・非エンジニアでも読める。書ける？
・ステップ定義でコードを結びつけられる
・仕様書としても使える
・自動化できる