Open1
Github Copilot Chatを活用してTDDを実践し、コードのドキュメント化も行う
ふじしろ前提の整理/前準備
やりたいこと
TDDのフローで開発しつつ、ドキュメントの生成までAIにやってもらう。
狙いは以下
- テストリストを仕様ドキュメントとして整備する
- docコメントをAIに作ってもらうことで人による国語力の差を埋める（標準化）
使うところと使わないところの区分
- テストコードはAiを使わず自分で書く（仕様は人が決める）
- 実装/リファクタ時はAIを積極的に活用する（ただしGreenは最小限にすることを意識する）
-
/docコマンドはメソッドに対して使う- ドメインモデルなどは自分で書いたほうがいいかも？（人の定義が先な気がする）
- それ以外のクラスとかは
/docsでもいいかも？
TDDのフローについて
ステップ1. テストリスト
ステップ2. ひとつテストを書く
ステップ3. テストを成功させる
ステップ4. 必要に応じてリファクタリングを行う
ステップ5. テストリストが空になるまでステップ2に戻って繰り返す
https://t-wada.hatenablog.jp/entry/canon-tdd-by-kent-beck より抜粋
Github Cpilot Chat コマンド
コマンド一覧（`/help`コマンドより）
| コマンド名 | 説明 (英語) | 説明 (日本語) |
|---|---|---|
| /tests | Generate unit tests | ユニットテストを生成 |
| /simplify | Simplify the code | コードを簡素化 |
| /fix | Fix problems and compile errors | 問題を修正し、コンパイルエラーを解消 |
| /explain | Explain how the code works | コードの動作を説明 |
| /doc | Document the current selection of code | 現在選択されたコードを文書化 |
| /feedback | Steps to provide feedback | フィードバックを提供する手順 |
※/helpを実行することで一覧表示される
Docの記載は/docコマンドに任せる。
Docコマンドで思ったようなドキュメントが生成されない場合は実装の不備を疑っても良いかもしれない。
実装フロー
- テストリストを書く
2. テストファイルの作成
3. 末尾にテストリストを作成
4. 必要に応じてテストリストを追加/修正する - リストから一つ選んでテストコードを書く（RED）
4. ここは自分で行う。命名などもしっかりやる。
5. 自分でやっておくことで、実装コードのほうでAIが補完ミスを犯してもテストで検知することができる。 - 最小限の実装コードでテストを成功させる（GREEN）
6. AIの力を借りてもよいが、この段階では最小限の実装コードにすることを意識する - 必要に応じてリファクタリンスを行う（リファクタ）
8. AIの力を積極的に活用
9./docコマンドを使ってドキュメントも作成 - テストリストが空になるまでステップ2に戻って繰り返す
事例集
テストファイルの末尾にテストリストを書いて対応している