読みました！！
https://booth.pm/ja/items/5372853
最近堅い本ばかり読んでたからライトなもの読みたくて初めてBoothで本買った。ダンジョンマップというものを理解するのに苦労したが面白かった。なんかプログラミングしてるっていう気が久しぶりにした。
Unityの本だけどGoで頑張って書いた軌跡
モチベーション
GitHub Copilotを使いこなしている人との差を感じるようになってきたから
AI補助とテストの関係に興味があったから
TDD関連だから
ゲームプログラミングが面白そうだったから
テストをAIが作ってくれる未来を想像していたが逆の思想でそっちのほうが納得感があったからもっと知りたくなった
感想
CopilotやChatGPTのようなAI補助が当たり前になってきてテストは自分で書くのではなくて実装からAIに作ってもらえないかなみたいな意見をちらほら見かけてきた。
私はテストは開発のサイクルの一部と考えているのでテストという工程を省くのはなんだか腑に落ちない感じはあったけど、テストを書くということは工数をかなり使うのは事実なのでAIに提案してもらったテストをチェックして修正して実行して開発してみたいなサイクルに変わっていくのかなとぼんやり思っていた。
で、こちらの書籍の感想文をXで見かけてテストじゃなくて実装を作成してもらうのかーーーと衝撃とともにすごい納得感があった。
単体テストの使い方/考え方では単体テストはテスト対象の振る舞いをテストするものとたしか書かれていた。
実装したいクラスや関数の振る舞いをテストとして書いてAIの入力に渡すことはこれ以上ない入力でしょう。
実装よりもテストの方がはるかに多くのことを語ってくれる気がする。
しかも、テストをしっかり書けば書くだけ実装の信頼度を上げられる可能性が高まりそう。
もしかしたらテストを仕様書として扱うRSpecのようなBDD系のテスティングフレームワークの方が有利になっていくこともあるかもしれない。
実際やってみた感想としては思っていたよりは正解の実装を提案はしてくれなかった。しかし、これはわたしが書籍に書かれているダンジョン生成アルゴリズムを理解しきれていないことがけっこう影響していると思う。期待する実装を提案してくれなかったときにテストを追加するなりコメントを書くなり適切にできていればもう少し精度は上がったように思う。
そもそもGoで書籍に書かれているようなゲームロジックを書いてGitHubに公開している人も少ないだろうしそこらへんもCopilotの提案がいまいちだった理由なのかもしれない。
とはいえ、8割くらいはCopilotの提案したコードでテストは通せたので十分とも言える。
AIが日に日に進化していくなかでテストを書くことはなくなってしまうのかなと思っていたがまだ大丈夫そうだ。
テストをコードの品質担保を目的として書いている場合はAIにやらせたほうがいいのかもしれない。人がやるには退屈すぎる
CopilotでTDDを実践し、爆速で高品質な実装を生産していくにはテスト力が重要。今まで以上にテストが重要視される未来が来る...かもしれない。
なんにせよシンプルにTDDで実装していくのが楽しかったのでTDDの理解深めたい人におすすめの良書でした。