テストは、判定基準の言い換えです
「残高が足りなければ購入できない」という判定基準があるなら、テストはその文をそのまま実行できる形にしたものです。
判定基準がないままテストを書くと、いま動いている実装をなぞるだけになります。それでは、実装が間違っていてもテストは通ります。
判定基準から、テストを起こす
レベル 1・実践テストで確かめる約90分
先に読む回：仕様に何を書き、何を書かないか
この回でできるようになること
- 完成の判定基準から、実行できるテストを起こせる
- うまくいく場合だけでなく、境目と失敗する場合もテストにできる
おさえておくこと
3種類を書きます
- うまくいく場合
- 想定どおりの入力で、想定どおりの結果になる。
- 境目
- 0件のとき。上限ちょうどのとき。最初と最後。
- 失敗する場合
- 入力が足りない、権限がない、外部が落ちている。
AIに任せると、1つめだけが厚くなりがちです。2つめと3つめは、こちらから指定してください。
テストが通ることと、正しいことは違います
生成されたテストは、生成された実装に都合よく合わせられることがあります。両方を同じ相手に任せたときは、特に注意が必要です。
- テストを読んで、判定基準のどれを確かめているか言えるか
- 実装をわざと壊したときに、そのテストが落ちるか
2つめは強力です。落ちないテストは、何も確かめていません。
ここまでで分からないところがあれば、この回の本文だけを使って答えてもらえます（任意・自分のAPIキーが必要です）。
この回では扱わないこと
- テストフレームワークの使い方
- カバレッジ率の目標設定
やってみる
自分のリポジトリで約75分
判定基準1つを、3種類のテストにする
自分で書いた判定基準を1つ選び、うまくいく場合・境目・失敗する場合の3種類のテストを書きます。最後に、実装をわざと壊して落ちることを確かめます。
やること
- 「『何が正しいか』を先に決める」の回で書いた判定基準から、1つ選びます。
- うまくいく場合のテストを書きます。
- 境目のテストを書きます。0件、上限ちょうど、最初と最後などです。
- 失敗する場合のテストを書きます。入力が足りない、権限がない、など。
- 実装を1行だけわざと壊します。条件を反転させるのが手軽です。
- テストが落ちることを確かめ、実装を戻します。落ちなかったテストは書き直します。
できあがるもの：3種類のテストと、わざと壊したときの実行結果
できたかどうかの確かめ方
対応表をたどる自分で採点する
どの基準を確かめているか言えるか
書いたテストを1つずつ読み、それが判定基準のどれを確かめているかを言ってください。どの基準にも紐づかないテストがあれば、その理由を書きます。
基準との対応
- まだ
- テストが何を確かめているか、実装を読まないと分からない。
- できた
- 各テストが、どの判定基準に対応するか言える。
- よくできた
- どの基準にも対応しないテストを見つけ、残すか消すかを決めている。
実際に動かして確かめる実行した結果で確かめる
壊したときに、落ちるか
実装を1行わざと壊した状態でテストを実行し、落ちることを出力で示してください。そのあと実装を戻し、通ることも示します。
pnpm test
落ちて、戻して、通る
- まだ
- 壊しても通ってしまうテストがある。
- できた
- 壊すと落ち、戻すと通ることを、両方の出力で示している。
- よくできた
- 落ちなかったテストを書き直し、書き直したあとの結果まで示している。
この回の情報の出どころ
この回の記録
書いた内容はこのブラウザの中だけに残ります。送信はしません。 成果物そのものではなく、どこにあるか（ファイルの場所、ブランチ名など）を書いてください。 鍵やパスワードは書かないでください。
確かめた結果
どの基準を確かめているか言えるか
壊したときに、落ちるか
置き場所を書き、すべての確認を「できた」以上にすると、記録つきの完了になります。
AIに見てもらう（任意）
使わなくても、すべての回は完了できます作ったものを、この回の観点表に照らして見てもらえます。返ってくるのは助言であって、 合否ではありません。完了にするかどうかを決めるのは、いつでもあなたです。 自分のAPIキーを使うため、料金はご自身のアカウントに請求されます。
先に、上の「この回の記録」ですべての確認に自分で評価を付けてください。 モデルの評価を先に見ると、自分の判断がそれに引きずられます。
キーはこの実行にのみ使われ、保存もログ出力もしません。ブラウザにも残らないため、ページを離れると再入力が必要です。
APIキーを発行する