2026.09.18
カテゴリ： AI 人工知能
STEP 6では、STEP 5までの「人間が実行して確認する」から、 テストコードそのものを資産として残し、Codexがコードを変更するたびに自動検証できる開発へ進みます。
STEP 6 — pytest・テスト・デバッグ
学習期間：4日
テーマ：単体テスト・正常系・境界値・異常系・回帰テスト
実習：CSV変換処理のテストをCodexに作らせる
到達目標：「動いた」ではなく、自動テストによって正しさを確認できる
テーマ：単体テスト・正常系・境界値・異常系・回帰テスト
実習：CSV変換処理のテストをCodexに作らせる
到達目標：「動いた」ではなく、自動テストによって正しさを確認できる
6-1. このSTEPのゴール
STEP 5まででは、
```text id="r5bnt1"
Codexが変更
↓
git diff
↓
人間が確認
↓
python main.py
↓
動いた！
↓
commit
Codexが変更
↓
git diff
↓
人間が確認
↓
python main.py
↓
動いた！
↓
commit
としていました。
しかし、
> **「動いた」と「正しい」は違います。**
例えばCSV変換ツールなら、
```text id="m76hgi"
UTF-8 → OK
CP932 → ？
空ファイル → ？
0バイト → ？
存在しない → ？
列不足 → ？
不正データ → ？
かもしれません。
そこでpytestを導入します。
```text id="r8oxz5"
Codexが変更
↓
git diff
↓
pytest
↓
─────────────
27 passed
─────────────
↓
commit
Codexが変更
↓
git diff
↓
pytest
↓
─────────────
27 passed
─────────────
↓
commit
これがSTEP 6で作りたい状態です。
---
# 6-2. テストコードとは
例えば、
```python id="n8hpwa"
def add(a, b):
return a + b
という関数があります。
人間なら、
```text id="c6qk8w"
add(2, 3)
↓
5ならOK
add(2, 3)
↓
5ならOK
と確認できます。
これをコードにすると、
```python id="sqh5xe"
def test_add():
assert add(2, 3) == 5
となります。
つまりテストとは、
```text id="oxqv0v"
入力
↓
処理
↓
実際の結果
↓
期待した結果と比較
↓
PASS / FAIL
入力
↓
処理
↓
実際の結果
↓
期待した結果と比較
↓
PASS / FAIL
を自動化したものです。
---
# 6-3. assertとは
テストでは頻繁に、
```python id="r1aiv6"
assert actual == expected
が登場します。
意味は、
actualはexpectedと同じであるはず
です。
例えば、
```python id="amc31g"
result = add(2, 3)
result = add(2, 3)
assert result == 5
なら、
```text id="lxt10a"
result = 5
expected = 5
5 == 5
↓
PASS
です。
もし、
```text id="xjv8ss"
result = 4
expected = 5
result = 4
expected = 5
4 == 5
↓
FAIL
↓
FAIL
なら、テストが失敗します。
---
# 6-4. pytestとは
pytestはPythonで広く使われているテストフレームワークです。
例えば、
```text id="zzllh6"
project/
│
├─ main.py
├─ csv_utils.py
│
└─ tests/
└─ test_csv_utils.py
という構造にして、
```powershell id="p20z18"
pytest
pytest
を実行すると、テストを探して実行してくれます。
最初は、
> **pytest = Pythonプログラムを自動チェックする仕組み**
くらいの理解で十分です。
---
# 6-5. pytestを準備する
学習用Python環境で、
```powershell id="xvm88u"
python -m pip install pytest
としてpytestを導入します。
確認は、
```powershell id="tm4q04"
python -m pytest --version
python -m pytest --version
です。
実行も最初は、
```powershell id="2v8f96"
python -m pytest
とすると、「今使っているPython環境のpytest」を意識しやすくなります。
特に複数のPython環境がある場合には、この書き方が分かりやすいです。
6-6. 最初のテストを作る
例えば
csv_utils.py
に、```python id="xihybv"
def convert_name(name):
return name.strip()
def convert_name(name):
return name.strip()
があるとします。
`tests/test_csv_utils.py` を作ります。
```python id="h5ifpw"
from csv_utils import convert_name
def test_convert_name():
result = convert_name(" Tanaka ")
assert result == "Tanaka"
実行します。
```powershell id="1tx1n8"
python -m pytest
python -m pytest
成功すれば、
```text id="9qx0cy"
passed
となります。
これが最初の自動テストです。
6-7. Test Caseとは
一つ一つの確認条件を Test Case（テストケース）と呼びます。
例えばCSV読み込みなら、
```text id="kxmb24"
Case 1
UTF-8 CSV
Case 1
UTF-8 CSV
Case 2
CP932 CSV
CP932 CSV
Case 3
空CSV
空CSV
Case 4
存在しないCSV
存在しないCSV
のように複数のケースがあります。
重要なのは、
> **一つ動いたから全部動く**
とは考えないことです。
---
# 6-8. 正常系とは
まず最も普通の使い方です。
例えば、
```text id="2ev7gl"
input.csv
name,department
Tanaka,Sales
Suzuki,Development
を正常に読み込める。
これが 正常系（Happy Path）です。
テストなら概念的には、
```python id="nhosrr"
def test_read_csv():
result = read_csv("sample.csv")
def test_read_csv():
result = read_csv("sample.csv")
assert len(result) == 3
のようになります。
---
# 6-9. 「正常に終了した」だけでは足りない
例えば、
```text id="uvd2cl"
python main.py
Exit Code 0
だったとします。
しかし実際には、
```text id="rggst5"
期待
期待
100件
実際
97件
かもしれません。
だからテストでは、
```text id="k8dr8d"
実行できた？
+
件数は正しい？
+
値は正しい？
+
形式は正しい？
まで確認します。
6-10. 異常系とは
次は、想定されるエラーです。
例えば、
```text id="0dh4no"
存在しないファイル
存在しないファイル
があります。
Pythonでは `FileNotFoundError` が発生する設計なら、pytestでそのこと自体を確認できます。
```python id="ptks3q"
import pytest
def test_missing_file():
with pytest.raises(FileNotFoundError):
read_csv("not_found.csv")
これは、
FileNotFoundErrorが発生すればPASS
というテストです。
つまり「エラーが出たから失敗」ではありません。
期待しているエラーが正しく発生することも、正しい動作です。
6-11. 正常系と異常系をセットで考える
例えば、
```text id="mjqudl"
read_csv()
read_csv()
正常系
├─ UTF-8
└─ CP932
├─ UTF-8
└─ CP932
異常系
├─ ファイル不存在
├─ 読み込み不能
└─ 不正データ
├─ ファイル不存在
├─ 読み込み不能
└─ 不正データ
のように考えます。
Codexに、
```text id="i9wcr3"
read_csv()について、
テストすべきケースを洗い出してください。
まだテストコードは作成しないでください。
正常系と異常系に分けて、
各ケースについて
・入力
・期待結果
・なぜ必要か
を説明してください。
と依頼すると良いでしょう。
ここでも、
```text id="28cg2f"
いきなりテストを書く
いきなりテストを書く
ではなく、
```text id="esjgqx"
Explore
↓
Test Plan
↓
人間が確認
↓
Test Code
と進めます。
6-12. 境界値とは
次に非常に重要なのが Boundary Value（境界値）です。
例えば、
CSVは最大1000件まで処理する
という仕様なら、
```text id="cwlb1q"
999件
1000件
1001件
999件
1000件
1001件
が重要です。
なぜならバグは、
```text id="85g5vb"
普通の値
より、
```text id="3t4wy5"
0
1
最大値
最大値+1
空
0
1
最大値
最大値+1
空
など、**境界付近**で起きやすいからです。
---
# 6-13. CSVツールの境界値
CSVなら例えば、
```text id="8cy27v"
0行
1行
ヘッダーのみ
データ1件
空文字
列数1
列数最大
非常に長い文字列
などが候補になります。
全部をテストする必要はありません。
重要なのは、
どこが境界なのかを考える習慣
です。
6-14. Codexに境界値を探させる
これはCodexがかなり役立つ部分です。
```text id="krtdka"
このCSV変換処理を調査して、
境界値になりそうな条件を洗い出してください。
このCSV変換処理を調査して、
境界値になりそうな条件を洗い出してください。
まだコードやテストは変更しないでください。
各候補について、
・境界値
・境界の直前
・境界そのもの
・境界の直後
・想定される問題
・境界の直前
・境界そのもの
・境界の直後
・想定される問題
を整理してください。
人間が思いつかなかったケースを発見することがあります。
---
# 6-15. テストをCodexに作らせる
Test Planを確認したら、
```text id="upmht5"
先ほどのTest Planから、
まず正常系のpytestを作成してください。
対象：
csv_utils.py
テストはtestsディレクトリに作成してください。
まだ本体コードは変更しないでください。
作成後、
追加したテストケースを説明してください。
とします。
重要なのは、
テスト作成のために本体コードまで勝手に直させない
ことです。
6-16. テストを実行させる
テスト作成後、
```text id="ntfb3i"
作成したpytestを実行してください。
作成したpytestを実行してください。
本体コードはまだ変更しないでください。
結果について、
・実行したコマンド
・テスト総数
・PASS
・FAIL
・FAILしたテストの原因
・テスト総数
・PASS
・FAIL
・FAILしたテストの原因
を報告してください。
とします。
例えば、
```text id="whk1ap"
12 tests collected
10 passed
2 failed
となったとします。
ここで、
2件失敗した → すぐ本体を修正
とはしません。
6-17. FAILは「悪いこと」ではない
これは大事な考え方です。
テストがFAILしたら、
```text id="0r0fdu"
テスト失敗
↓
Codex失敗
テスト失敗
↓
Codex失敗
ではありません。
むしろ、
```text id="m7qzbb"
テスト失敗
↓
問題を発見できた
可能性があります。
例えば、
```text id="ejmtz5"
CP932 test
↓
FAIL
CP932 test
↓
FAIL
なら、
> 「CP932対応に問題がある」
ことを自動的に発見できたわけです。
テストの価値が出ています。
---
# 6-18. ただし「テストが間違っている」こともある
ここがAI時代には特に重要です。
Codexが作ったテストだから正しいとは限りません。
例えば仕様が、
```text id="95fvt3"
空CSV
↓
空リストを返す
なのにCodexが、
```text id="o01ftc"
空CSV
↓
例外を発生させるべき
空CSV
↓
例外を発生させるべき
と勝手に想定してテストを書くかもしれません。
その場合、
```text id="yl3tvl"
本体コードが間違い
ではなく
テスト仕様が間違い
です。
6-19. テスト失敗時の調査
そこで、
```text id="a1bbvj"
失敗しているテストについて調査してください。
失敗しているテストについて調査してください。
まだ本体コードもテストコードも変更しないでください。
各FAILについて、
1. テストが期待している結果
2. 実際の結果
3. 本体コードの問題の可能性
4. テストコードの問題の可能性
5. 仕様が不明な部分
を説明してください。
とします。
これがデバッグです。
---
# 6-20. Debuggingとは
Debugging（デバッグ）は、
> **問題の原因を調査して取り除く作業**
です。
大事なのは、
```text id="mlbjrx"
エラー
↓
とにかく修正
ではなく、
```text id="05auu6"
エラー
↓
再現
↓
情報収集
↓
原因候補
↓
原因特定
↓
修正
↓
再テスト
エラー
↓
再現
↓
情報収集
↓
原因候補
↓
原因特定
↓
修正
↓
再テスト
という順番です。
STEP 4のExploreと同じ考え方ですね。
---
# 6-21. エラーメッセージを読ませる
例えばpytestで、
```text id="1bdxkj"
FAILED tests/test_csv_utils.py::test_cp932
となったら、
```text id="67k0a4"
このpytestの失敗を調査してください。
このpytestの失敗を調査してください。
エラーメッセージと関連コードを確認して、
・どのテストが失敗したか
・どこで失敗したか
・期待値
・実際値
・原因候補
・どこで失敗したか
・期待値
・実際値
・原因候補
を説明してください。
まだ修正しないでください。
とCodexに依頼します。
---
# 6-22. テストを先に作る考え方
例えば、新しく、
> CP932対応を追加する
とします。
従来なら、
```text id="b5pkjz"
コード変更
↓
動かす
↓
確認
でした。
しかし、
```text id="84q34q"
期待する動作をテストとして定義
↓
テスト実行
↓
FAIL
↓
本体コードを実装
↓
テスト実行
↓
PASS
期待する動作をテストとして定義
↓
テスト実行
↓
FAIL
↓
本体コードを実装
↓
テスト実行
↓
PASS
という進め方もできます。
これは後々、テスト駆動的な開発を理解するときにも役立ちます。
STEP 6では厳密なTDDを覚える必要はありません。
**「実装前に完成条件をテストとして書ける」**
という感覚をつかめれば十分です。
---
# 6-23. Red → Green
簡単に表すと、
```text id="8qrptm"
新しいTest
↓
FAIL
↓
RED
↓
実装・修正
↓
PASS
↓
GREEN
です。
ここで大事なのは、
最初にFAILすることを確認する
ことです。
最初からPASSしていたら、
```text id="kpxk9q"
すでに機能が存在した？
すでに機能が存在した？
テストが機能を確認できていない？
条件が間違っている？
という疑問が出ます。
---
# 6-24. 回帰テスト
STEP 4でも出てきたRegressionです。
例えば、
```text id="cbl59k"
Version 1
UTF-8対応
↓
test_utf8 PASS
Version 2
CP932対応追加
↓
test_cp932 PASS
でも
test_utf8 FAIL
なら、既存機能を壊しています。
そこで、
```text id="z1fx9b"
新しいテスト
+
昔からあるテスト
↓
全部実行
新しいテスト
+
昔からあるテスト
↓
全部実行
します。
これが**Regression Test（回帰テスト）**の重要な役割です。
---
# 6-25. バグを直したらテストを残す
例えば、
> 空CSVでクラッシュする
というバグを発見したとします。
修正だけすると、
```text id="ec4wzq"
Bug
↓
Fix
↓
半年後
↓
別変更
↓
同じBug復活
する可能性があります。
そこで、
```text id="y2i1ri"
Bug発見
↓
再現Test作成
↓
FAIL
↓
Fix
↓
PASS
↓
Testを残す
Bug発見
↓
再現Test作成
↓
FAIL
↓
Fix
↓
PASS
↓
Testを残す
とします。
すると将来、
```text id="fud3h1"
誰かが変更
↓
pytest
↓
昔のBugが復活
↓
FAIL
と自動的に検出できます。
6-26. 「バグはテスト資産に変える」
このSTEPでぜひ覚えてほしい考え方です。
```text id="m3p29d"
バグ
↓
嫌な出来事
バグ
↓
嫌な出来事
だけではありません。
```text id="qup4r2"
バグ
↓
再現条件を理解
↓
Testにする
↓
Regression Testとして保存
とすれば、
一度経験したバグを二度と見逃しにくくする
ことができます。
6-27. fixtureとは
pytestを使っていると
fixture
という言葉が出てきます。例えば複数テストで、
```text id="s50uw3"
UTF-8 CSVを作る
UTF-8 CSVを作る
CP932 CSVを作る
一時フォルダを作る
といった準備が必要になります。
fixtureは簡単に言えば、
> **テストに必要な準備を再利用する仕組み**
です。
STEP 6ではfixtureを高度に使う必要はありません。
まずはpytestの `tmp_path` が便利です。
---
# 6-28. tmp_path
テストのために、
```text id="3q2kwj"
test.csv
test2.csv
test3.csv
をプロジェクトへ大量に残す必要はありません。
pytestの
tmp_path
を使えます。例えば、
```python id="7v59t9"
def test_read_csv(tmp_path):
csv_file = tmp_path / "sample.csv"
def test_read_csv(tmp_path):
csv_file = tmp_path / "sample.csv"
csv_file.write_text(
"name,department\nTanaka,Sales",
encoding="utf-8"
)
result = read_csv(csv_file)
assert len(result) == 2
テスト専用の一時領域でファイルを作れます。
CSV処理のテストではかなり便利です。
---
# 6-29. parametrize
例えば、
```text id="g8pfpj"
UTF-8
CP932
UTF-8 BOM
について似たテストを書く場合があります。
pytestでは
parametrize
を使ってまとめる方法があります。概念として、
```text id="cl2kxq"
同じテスト処理
同じテスト処理
入力A → UTF-8
入力B → CP932
入力C → UTF-8 BOM
入力B → CP932
入力C → UTF-8 BOM
とできます。
ただし、最初から無理に使う必要はありません。
まず、
```text id="muczb9"
test_utf8()
test_cp932()
test_utf8_bom()
と別々に書いて理解してから、Codexに、
```text id="cyv3g6"
この3つのテストは
pytest.mark.parametrizeを使うと
分かりやすくなりますか？
この3つのテストは
pytest.mark.parametrizeを使うと
分かりやすくなりますか？
まだ変更せず説明してください。
と聞いてみるのがおすすめです。
---
# 6-30. Mockはこの段階では深入りしない
テストを調べていると、
```text id="1c7iys"
Mock
Monkeypatch
Patch
なども出てきます。
外部API、時刻、メール送信、ファイルシステムなどをテストするときに重要になります。
しかしSTEP 6では、
```text id="u4c2bt"
純粋な関数
↓
CSV
↓
ファイル
↓
例外
純粋な関数
↓
CSV
↓
ファイル
↓
例外
くらいを中心にします。
Mockは必要になったときに学べば十分です。
---
# 6-31. テストしやすいコードとは
ここで面白いことが起きます。
例えば、
```python id="gdp00c"
def process():
# GUIから値取得
# CSV読込
# 文字コード判定
# データ変換
# ファイル保存
# MessageBox表示
のような巨大な関数はテストしにくいです。
一方、
```text id="9ldgt7"
detect_encoding()
↓
read_csv()
↓
validate_rows()
↓
convert_rows()
↓
save_csv()
detect_encoding()
↓
read_csv()
↓
validate_rows()
↓
convert_rows()
↓
save_csv()
と分かれていると、各関数を個別にテストできます。
つまり、
> **テストを書こうとすると、コード設計の問題も見えてくる**
わけです。
STEP 4のリファクタリングとつながります。
---
# 6-32. Unit Testとは
Unit Test（単体テスト）は、
> **小さな機能単位を個別に確認するテスト**
です。
例えば、
```text id="4lhz6n"
detect_encoding()
↓
Unit Test
convert_row()
↓
Unit Test
normalize_name()
↓
Unit Test
です。
最初からプログラム全部をテストするより、原因を特定しやすくなります。
6-33. Codexにテスト対象を分析させる
既存コードなら、
```text id="5ytg52"
このRepositoryを調査して、
Unit Testを追加する価値が高い関数を
候補として挙げてください。
このRepositoryを調査して、
Unit Testを追加する価値が高い関数を
候補として挙げてください。
まだテストは作成しないでください。
各候補について、
・関数名
・役割
・入力
・出力
・副作用
・テストしやすさ
・テストする価値
・役割
・入力
・出力
・副作用
・テストしやすさ
・テストする価値
を説明してください。
と依頼できます。
全部テストする必要はありません。
**重要な処理からテストする**ことを学びます。
---
# 6-34. テストの品質もReviewする
Codexがテストを20個作ったとしても、
> 20個あるから安心
とは限りません。
例えば全部、
```text id="ynbt42"
正常なUTF-8
正常なUTF-8
正常なUTF-8
のような似たケースなら意味が薄いです。
そこで、
```text id="4vtnbr"
現在のpytestをレビューしてください。
現在のpytestをレビューしてください。
まだ変更しないでください。
次の観点で不足を調査してください。
・正常系
・異常系
・境界値
・文字コード
・空データ
・ファイル不存在
・Regression
・異常系
・境界値
・文字コード
・空データ
・ファイル不存在
・Regression
重複しているテストがあれば
それも指摘してください。
それも指摘してください。
とします。
---
# 6-35. テスト数より「何を守っているか」
重要なのは、
```text id="euhkrt"
100 tests
という数字ではありません。
```text id="f4w2ya"
このTestは何を保証する？
このTestは何を保証する？
です。
例えば、
```text id="hpuobc"
test_utf8
↓
UTF-8読込を守る
test_cp932
↓
CP932読込を守る
test_empty_csv
↓
空CSV処理を守る
test_missing_file
↓
不存在時の動作を守る
と説明できることが重要です。
6-36. Gitとpytestを組み合わせる
STEP 5と統合します。
```text id="n0p15j"
main
│
│ 正常
│
└─ feature/csv-encoding
│
↓
Codex Edit
↓
git diff
↓
pytest
↓
┌─────┴─────┐
↓ ↓
PASS FAIL
│ │
Review Debug
│ │
↓ ↓
commit Fix
↓
pytest
main
│
│ 正常
│
└─ feature/csv-encoding
│
↓
Codex Edit
↓
git diff
↓
pytest
↓
┌─────┴─────┐
↓ ↓
PASS FAIL
│ │
Review Debug
│ │
↓ ↓
commit Fix
↓
pytest
これでかなり実際の開発に近づきます。
---
# 6-37. Commit前にpytest
自分のルールとして、
```text id="1upz1z"
Commitする前に
git status
↓
git diff
↓
pytest
↓
全部PASS？
↓
git add
↓
git diff --staged
↓
commit
としてみましょう。
この習慣はCodex利用と非常に相性が良いです。
6-38. Codexへの完成指示も変わる
STEP 2では、
```text id="im3x4h"
変更後に動作確認してください。
変更後に動作確認してください。
程度でした。
STEP 6以降は、
```text id="tbsxbm"
変更後に既存のpytestをすべて実行してください。
今回追加した機能について
必要なテストも追加してください。
既存テストを変更する必要がある場合は、
変更理由を説明してください。
すべてのテスト結果を報告してください。
とできます。
Codexへの仕事の依頼そのものが進化しています。
6-39. 1日目 — pytest基礎
1日目は、
```text id="2agbyh"
pytest導入
↓
最初のtest
↓
assert
↓
PASS
↓
わざとFAIL
pytest導入
↓
最初のtest
↓
assert
↓
PASS
↓
わざとFAIL
を体験します。
実習：
```text id="m37dpa"
① pytest導入
② tests/作成
③ test_csv_utils.py作成
④ 正常系テスト1個
⑤ pytest実行
⑥ 本体をわざと変更
⑦ FAILを確認
⑧ git restore
⑨ pytest
⑩ PASSを確認
ここでは、
テストが壊れたコードを検出する
ことを体験するのが目的です。
6-40. 2日目 — 正常系・異常系・境界値
CSV処理についてTest Planを作ります。
例えば、
| 種類 | ケース | 期待 |
|---|---|---|
|
正常系
|
UTF-8 | 正常読込 |
|
正常系
|
CP932 | 正常読込 |
|
正常系
|
1件 | 正常処理 |
|
境界値
|
空CSV | 仕様通り |
|
境界値
|
ヘッダーのみ | 仕様通り |
|
異常系
|
ファイル不存在 | 所定のエラー |
|
異常系
|
不正データ | 所定の処理 |
そしてCodexにテストを作らせます。
6-41. 3日目 — デバッグ
3日目は、わざと不具合を入れます。
例えば、
```text id="89vlb5"
UTF-8は動く
UTF-8は動く
CP932だけ壊す
そして、
```powershell id="p9rbmc"
python -m pytest
を実行します。
Codexには、
```text id="g77ikq"
pytestの失敗を調査してください。
pytestの失敗を調査してください。
まだ修正しないでください。
FAILしたテストから、
原因となる処理を追跡してください。
原因となる処理を追跡してください。
原因候補ではなく、
可能な範囲でコード上の根拠まで確認してください。
可能な範囲でコード上の根拠まで確認してください。
と依頼します。
その後、
```text id="9xjjwd"
修正Plan
↓
人間が確認
↓
Fix
↓
pytest
まで行います。
6-42. 4日目 — Regression Test
最後は実際のバグを想定します。
例えば、
空CSVでクラッシュする
というバグです。
```text id="kswdr7"
Bug発見
↓
再現条件を確認
↓
Regression Test作成
↓
FAIL確認
↓
Fix
↓
そのTestだけ実行
↓
PASS
↓
全Test実行
↓
全部PASS
↓
Commit
Bug発見
↓
再現条件を確認
↓
Regression Test作成
↓
FAIL確認
↓
Fix
↓
そのTestだけ実行
↓
PASS
↓
全Test実行
↓
全部PASS
↓
Commit
この一連をCodexと行います。
---
# 6-43. 4日間の学習計画
| 日 | テーマ | 実習 | 到達目標 |
| ------- | ----------- | ------------------ | ---------------- |
| **1日目** | pytest基礎 | assert、PASS/FAIL | 自動テストを実行できる |
| **2日目** | Test Design | 正常系・異常系・境界値 | テストケースを設計できる |
| **3日目** | Debug | FAIL→原因調査→修正 | テストから不具合を追跡できる |
| **4日目** | Regression | Bug→Test→Fix→全Test | 過去の不具合をテスト資産にできる |
---
# 6-44. STEP 6で覚える用語
| 用語 | 意味 |
| ------------------- | ----------------- |
| **pytest** | Pythonのテストフレームワーク |
| **Test Case** | 一つのテスト条件 |
| **assert** | 実際値と期待値を確認 |
| **Unit Test** | 小さな機能単位のテスト |
| **Normal Case** | 正常系 |
| **Error Case** | 異常系 |
| **Boundary Value** | 境界値 |
| **Regression** | 変更で既存機能が壊れること |
| **Regression Test** | 過去・既存機能を守るテスト |
| **fixture** | テストの準備を共通化 |
| **tmp_path** | pytestの一時ディレクトリ |
| **Debugging** | 不具合原因を調査・修正する作業 |
特に、
**Normal / Boundary / Error / Regression**
の4種類を意識してください。
---
# 6-45. STEP 6以降のCodex基本指示
ここまで来ると、Codexへの依頼もかなり実践的になります。
```text id="vv0m4m"
【目的】
CSV文字コード処理を改善する。
【Explore】
現在の実装と関連する既存テストを調査する。
まだ変更しない。
【Plan】
変更内容と、
追加・変更すべきテストを計画する。
まだ実装しない。
【Edit】
承認したPlanだけを実装する。
【Test】
正常系
境界値
異常系
Regression
を考慮する。
【Verify】
関連テストだけでなく
既存pytestをすべて実行する。
【Review】
git diffを確認し、
目的外の変更がないか確認する。
【Report】
・変更ファイル
・追加テスト
・実行コマンド
・PASS数
・FAIL数
・未確認事項
を報告する。
これでCodexは単なるコード生成器ではなく、
```text id="6frbhg"
調査
↓
設計
↓
実装
↓
テスト作成
↓
実行
↓
デバッグ
↓
報告
調査
↓
設計
↓
実装
↓
テスト作成
↓
実行
↓
デバッグ
↓
報告
まで担当する開発Agentに近づきます。
---
# 6-46. STEP 6確認問題
**Q1.** 「プログラムが実行できた」と「正しく動作した」の違いは？
**Q2.** 正常系・異常系・境界値とはそれぞれ何でしょう？
**Q3.** pytestがFAILしたとき、なぜすぐ本体コードを修正してはいけないのでしょう？
**Q4.** テストコード自体が間違っている可能性を考える必要があるのはなぜでしょう？
**Q5.** Regression Testは何のためにありますか？
**Q6.** バグ修正時に「再現テスト → Fix」とするメリットは？
**Q7.** なぜテスト数だけで品質を判断できないのでしょう？
**Q8.** Commit前にpytestを実行するメリットは？
---
# 6-47. STEP 6 合格実習
最後はCSV変換ツールに対して、Codexを使って次のテスト環境を作ります。
```text id="tfb01q"
CSV変換ツール
│
├─ UTF-8
├─ CP932
├─ 空CSV
├─ ヘッダーのみ
├─ ファイル不存在
└─ 不正データ
↓
pytest
↓
PASS / FAIL
ただし、いきなり、
テスト全部作って
とは頼みません。
自分で、
```text id="i7dwkk"
① RepositoryをExplore
↓
② テスト対象を選ぶ
↓
③ Test Caseを洗い出す
↓
④ 正常系を決める
↓
⑤ 境界値を決める
↓
⑥ 異常系を決める
↓
⑦ CodexにTest Codeを作らせる
↓
⑧ pytest
↓
⑨ FAILを調査
↓
⑩ 必要ならFix
↓
⑪ pytest
↓
⑫ 全Test PASS
↓
⑬ git diff
↓
⑭ git add
↓
⑮ commit
① RepositoryをExplore
↓
② テスト対象を選ぶ
↓
③ Test Caseを洗い出す
↓
④ 正常系を決める
↓
⑤ 境界値を決める
↓
⑥ 異常系を決める
↓
⑦ CodexにTest Codeを作らせる
↓
⑧ pytest
↓
⑨ FAILを調査
↓
⑩ 必要ならFix
↓
⑪ pytest
↓
⑫ 全Test PASS
↓
⑬ git diff
↓
⑭ git add
↓
⑮ commit
まで行います。
さらに、正常なコードを**わざと1か所壊してpytestを実行**してください。
```text id="qfgwjp"
正常コード
↓
意図的にBug
↓
pytest
↓
FAIL
↓
「テストがBugを発見した」
↓
git restore
↓
pytest
↓
PASS
ここまで体験して初めて、
テストは「動くことを確認するもの」だけではなく、「将来コードを壊したときに教えてくれる安全装置」
だと実感できます。
STEP 5とSTEP 6を組み合わせると、Codex利用の安全性はかなり上がります。
```text id="kwnk9f"
Codex
↓
Edit
↓
git diff
↓
pytest
↓
┌───────┴───────┐
↓ ↓
PASS FAIL
↓ ↓
Review Debug
↓ ↓
Commit Fix / Restore
↓ ↓
└───────→ pytest
Codex
↓
Edit
↓
git diff
↓
pytest
↓
┌───────┴───────┐
↓ ↓
PASS FAIL
↓ ↓
Review Debug
↓ ↓
Commit Fix / Restore
↓ ↓
└───────→ pytest
そしてここで、次の問題が出てきます。
毎回Codexへ、
```text id="ey6j2w"
Python 3.xを使って
既存機能を壊さず
pytestを全部実行して
GUIを勝手に変更せず
外部ライブラリを勝手に追加せず
……
と同じルールを書くのは面倒です。
そこで次の STEP 7「AGENTS.md」では、こうした プロジェクト固有のルールをRepository側に常駐させ、Codexが作業するときの基本ルールとして読ませる方法へ進みます。
STEP 0～6で「Codexを使う人間側の作法」を作り、STEP 7からは Codexが働きやすいRepositoryそのものを設計する段階に入ります。
お気に入りの記事を「いいね！」で応援しよう
[AI 人工知能] カテゴリの最新記事
-
アンソロピックのＩＰＯ目論見書の件 KIM… 2026.10.02
-
Microsoft Foundry Localを使って NPU付… 2026.09.29
-
ClaudeCodeもCodexもGoogle AIも全部やめ… 2026.09.28
【毎日開催】
15記事にいいね！で1ポイント
PR
Calendar
Category
カテゴリ未分類
(352)IT導入補助金
(63)IT
(157)AI 人工知能
(207)Windows
(53)Linux
(46)Android
(19)ｉＯＳ
(8)MAC
(9)Database
(9)ObsidianとかMarkdownとか
(13)仮想化技術
(17)Sikulix
(21)GSuiteのレガシー無料版 Ｇoogle Warkspace
(11)Google Apps
(3)DIGITAL AUDIO & VISUAL
(34)Audio & Visual
(35)MUSIC
(52)ROBOT WAR
(5)ChatGPTに聞いてみた
(9)会計業務
(8)風水
(5)萌える
(26)機動戦士ガンダム
(12)ツイン・ピークス
(2)政治とか
(30)プログラミング
(21)真空管
(3)読書
(12)Web
(7)autoCamp
(6)デジカメ
(17)天文
(19)東京ディズニーリゾート
(5)健康
(10)JAZZ
(2)ＢＣＬ とか アマチュア無線
(12)GAME
(3)STARWARS
(1)工場化
(3)脱カフェイン
(16)ボンゴフレンディ
(2)Leitzphone
(5)ビジネス
(9)Blue 青色 色彩
(9)第二種電気工事士
(2)株投資とか
(9)Googiehost
(5)Retropie
(5)nyoibox（如意箱）
(3)あつまれ偽装USBメモリの杜
(7)ZOHO
(0)グルメ
(11)ファイナンシャル
(6)エコ ロジー ノミー
(16)世の中
(60)Camp ＆ OutDoor
(8)アマチュア無線
(14)脳梗塞 リハビリ 闘病日記
(95)TRON
(3)MSX
(26)X API
(17)kintone および kintone API
(22)© Rakuten Group, Inc.
