テスト駆動開発、仮想マシン等々、繰り返し実行して、時には成果物を捨てたとしても、素早い実行とそのフィードバックが結果的により物事を先に進められるという事を認知させてくれたので素晴らしい
「最初から一発で上手く行くように入念に準備するのが正しい」なんていうのは呪いの言葉だなって
https://blog.magnolia.tech/entry/2018/05/15/230517

• 最初のテストは成功するコードと失敗しそうなコードでテストする
  • 失敗する条件はテストされるロジック側で変更する
  • わざと間違えたコードにする
  • そうすることでテストが正しく失敗することが保証される
• 失敗する可能性のある境界条件を考えて、そこを集中的にテストする
  • 集合の場合は空のときどうか
  • 数値の場合は0やマイナスだとどうか
  • そしてその結果は正しいけど本当に適切なのか（マイナスだと例外にすべきか）を考えるきっかけになる
• テストは全てを網羅することが望ましいが、フィールドを読み書きするだけの関数がバグを起こすとは思いにくい。
  • 実行されない完全なテストよりも、実行される不完全なテストのほうがマシである
  • 一番怪しい（クリティカル）な部分を集中的にテストする

• テストファーストと言うけども、一回コード書いて、テスト書いて、もう一度コード書き直すでも全然良い
  • 文字ベースの設計は難しくてもコード書いてると考えが整理されてくる
  • とりあえず動くものが作れれば、IOは見えてきている証拠だからあとはもっと良い形にするだけ

統合テストから書く

テストはE2Eテストだけで良い

• フロントとかバックエンドとかではなく、１アプリとして見るのでデータ部分(API)にモックは使わず、本物のバックエンドコードとDB構成を使う
• ローカル（や用意した環境）でコンテナなどを立ち上げてテストを走らせる
• テスト実行ごとにDBはダミーデータで初期化する
• モックを使って、フロントだけでテストできるように～とか考えるから辛い
• pushごとに走らせるコストが～とかあるなら、明示的なタイミングだけで手動で走らせて確認すれば良い（リリース前とか、1週間に一度とか）
• E2Eテストだけと言ったが、ある程度大きな機能であれば機能単位で画面無しでテストする
  • 〇〇登録処理とか

参考

• リーダブルテストコード
• テストコードにはテストの意図を込めよう
• JUnit 実践講座
• なぜ我々はユニットテストが書けないのか？
• 実装例から見る React のテストの書き方
• 単体テストはただの負債だから今すぐ書くのをやめるべき(かもしれない)
• テストは書かなくても良いが、検証が容易なように実装をしたほうが結果的に楽。そのための手法がテストを書くこと
  • 逆に言うと検証が容易な適切なコードを書けない人は適切なテストもかけない（なのでテストが無駄はある意味正しい）
• TDDはRed Green Refactoringのリズムが大事なので、このテストコードはすべてコミットしなければならぬ、という気持ちになると手が止まってしまってもったいない。別にテストはその場で捨てても良い
• プログラマーが毎日システムレベルのテストをしている
  • 「開発者（営業）、絶対コレ日常的に使ってないだろ」と思うことが多々あるので、コレ重要
• テストは仕様を確定させて完成形から逆算するわけではない。良くわからない領域を少しずつ減らしていき、わかった領域を確保しながらシステムを作っていく感覚