pytest強化シリーズ

はじめに

私は現在、本業でトラックドライバーとして働きながら、PythonやFlaskを使ったWebアプリケーション開発を独学しています。

この記事執筆時点で、累計学習時間は167時間です。

以前、個人開発中のアプリにあったpytestを見直したところ、テストは3件しかなく、

「テストはあるけれど、本当に大事なところを守れているのだろうか？」

という疑問が出てきました。

そこで、pytestを単なる動作確認ではなく、

一度見つけた問題を、同じ状態に戻さないための「事故防止台帳」

として育てることにしました。

第1段階では、3件だったテストを9件まで増やし、

AIへ渡すプロンプト
XSS対策
Gemini APIをモックした連携確認
GitHub Actionsですべてのpytestを実行

といった部分を確認できるようにしました。

今回はその続きとして、第2段階を進めました。

最終的にpytest全体は、

51 passed

まで増えました。

ただ、今回重視したのは「テスト件数を増やすこと」ではありません。

売上や商品データを扱うときに、今回想定した不正入力やDB保存失敗で、DBをおかしな状態にしないこと

を中心に確認しました。

今回の第2段階で確認したこと

大きく分けると、次の内容です。

売上入力の不正データを拒否する
間違った商品への売上登録を防ぐ
同じ商品・同じ日の売上が重複しないようDB側でも防ぐ
DB保存に失敗したら変更を元に戻す
商品登録・更新時の不正入力を拒否する
販売終了しても過去の売上履歴を残す
ダッシュボードの集計結果がDBと一致することを確認する

最初は、

「売上入力のテストを少し増やそう」

くらいのつもりでした。

しかし一つずつ確認していくと、

入力 → DB保存 → 履歴保持 → 集計表示

までつながっているため、想像以上に広い範囲になりました。

1. 売上入力は「1件でもおかしければ全部止める」

まず確認したのが、売上入力画面から送信されるデータです。

Webフォームから送られたデータをFlask側で受け取る処理を、この記事では「売上POST」と呼びます。

たとえば、

商品A  5個
商品B  3個

と入力して送信すると、

Flaskがその内容を受け取り、DBへ保存します。

ここで問題になったのが、

一部だけ不正なデータが混ざった場合

でした。

確認したケースには、

日付がおかしい
数量が空
数量に数字以外の文字が入っている
負の数量
小数
商品IDと数量の件数が合わない
商品IDが空
商品IDに数字以外の文字が入っている
同じ商品IDが重複
商品・数量の配列自体が空

などがあります。

修正前には、たとえば小数を整数へ変換してしまったり、不正な行だけを飛ばして正常な行を保存する経路がありました。

そこで方針を、

1件でも不正なデータがあれば、そのリクエスト全体を拒否する

に変更しました。

pytestではHTTP 400になることだけでなく、

POST前後でDailySalesの中身が変わっていないこと

まで確認しています。

つまり、

商品A：5 → 9へ変更予定
商品B：不正データ

↓ 全体を拒否

商品A：5のまま
商品B：保存されない

という状態を確認しています。

2. 「存在する商品なら何でもOK」ではなかった

次に確認したのが、売上を登録する対象の商品です。

商品IDが数字として正しくても、

DBに存在しない商品
売上日とは別の年月の商品
販売終了した商品

には売上を登録させたくありません。

そこでpytestを追加し、

不明商品
別月の商品
販売終了商品

をすべてHTTP 400で拒否するようにしました。

ここでも、

正常な商品を一緒に送っていてもDailySalesを変更しない

ことを確認しています。

販売終了した商品に過去の売上がすでに存在する場合も、

その履歴自体は変更されません。

3. DB自身にも「同じ日の売上は1件だけ」と覚えてもらう

アプリ側では以前から、

同じ商品・同じ日付の売上が存在すれば、新しい行を追加せず数量を更新する

という処理がありました。

しかし、DBそのものには、

同じ商品
+
同じ日付

を重複禁止にするルールがありませんでした。

そこで、

(product_id, date)

の組み合わせに一意制約を追加しました。

一意制約とは、簡単に言えば、

「この組み合わせはDB内に1つしか存在できません」

というルールです。

アプリ側で重複を避けるだけでなく、DB側でも拒否する二重チェックにしました。

pytestではFlaskの画面を通さず、テストDBへ直接同じ商品・同じ日付の売上を2件保存しようとして、

IntegrityError

になることを確認しています。

同一商品・同一日の重複については、

アプリ側の処理をすり抜けてもDB側の一意制約で止められる状態にしました。

今回は、この状態を作ることが目的でした。

4. マイグレーションも隔離したPostgreSQLで確認

DBの設計を変更したため、Alembicのマイグレーションも追加しました。

マイグレーションは、

DBの設計変更を履歴として残し、順番に適用するための仕組み

として理解しています。

今回追加した内容は、

DailySales(product_id, date)

へ一意制約を追加する変更です。

ただし、普段使っているPostgreSQLへいきなり適用するのは避けました。

通常環境とは別のDocker環境を作り、

空DBから最新状態までupgrade
既存DB相当の状態からupgrade
downgrade
再upgrade
既存データの件数・内容が変わっていないこと

を確認しました。

さらに重複INSERTを行い、PostgreSQL自身が一意制約違反として拒否することも確認しました。

検証後は、隔離環境のコンテナ・volumeなどを削除しています。

ここでも、

通常環境で試して問題が起きたら戻す

のではなく、

失敗しても通常環境へ影響しない場所で先に試す

ことを意識しました。

5. 保存失敗時はrollbackする

次に確認したのが、

入力は正常だったけれど、最後のDB保存で失敗した場合

です。

DBへの保存では、最後にcommit()を実行します。

簡単に言うと、

ここまでの変更を正式に保存する

処理です。

しかし、ここでエラーが起きる可能性もあります。

売上POSTの場合

例えば、

商品A：5個 → 9個へ更新予定
商品B：7個を新規追加予定

という変更を進めたあと、最後のcommit()でエラーになった場合です。

このとき、保存に失敗した変更を明示的に取り消し、DBセッションを戻す処理が必要になります。

そこで、

db.session.rollback()

を追加しました。

pytestではcommit()を意図的に失敗させ、

商品AのDailySales：quantity=5のまま
商品BのDailySales：新規追加されない
DailySales件数：変化なし

となることを確認しました。

商品POSTの場合

商品登録・更新側でも同じようにcommit()を意図的に失敗させています。

こちらでは、

既存商品の名前・価格・販売状態
新規商品の追加
DailySales

がPOST前の状態から変わっていないことを確認しました。

つまり、

入力検証だけでなく、最後の保存処理そのものが失敗した場合も、途中の変更を残さない

ことを回帰テストにしました。

6. 商品登録側も17種類の不正入力を確認

売上入力だけではなく、商品マスタを登録・更新する画面も確認しました。

修正前には、

入力項目の件数が合わなくてもzip()で余った値が無視される
数字以外の商品IDが送られる
存在しない商品IDが送られる
別月の商品IDが送られる
同じ商品IDを複数回送る
不正な価格が送られる
year・monthが空または数字ではない
month=0やmonth=13が送られる

といったケースを十分に拒否できていない経路がありました。

そこで17種類の不正入力ケースを追加しました。

修正前は、

17 failed

修正後は、

17 passed

となりました。

ここでも重要なのは、

HTTP 400を返すだけではなく、ProductとDailySalesがPOST前後で変わっていないこと

です。

商品登録でも、

すべて検証
↓
全部正常
↓
初めてDBを変更

という順番にしました。

正常系についても、

既存商品の更新
新規商品の追加
価格0円の商品
売上履歴を変更しないこと

を確認しています。

7. 販売終了しても過去の売上は消さない

このアプリでは、商品を販売終了にしてもDBから削除しません。

is_active=True
↓
is_active=False

とする「論理削除」を使っています。

これには理由があります。

商品そのものを削除してしまうと、その商品に紐づく過去の売上履歴まで扱いにくくなるためです。

今回pytestで、

商品行そのものは残る
Product IDは変わらない
is_active=Falseになる
過去のDailySalesは残る

ことを確認しました。

さらに、販売終了した商品の既存Product IDを再送信した場合も、

新しい商品を作る

のではなく、

同じProduct ID
↓
is_active=True

へ戻ることを確認しています。

その際、

Product件数が増えない
過去のDailySalesが変わらない
同じProduct IDを使い続ける

ことも確認しました。

この2つのテストは、追加した時点から成功しました。

つまり今回はコードを直したのではなく、

すでに正しく動いていた仕様を、今後壊れないようpytestに記録した

形です。

8. 最後はダッシュボードの集計まで確認

第2段階の最後に、ダッシュボードAPIも確認しました。

DBへ売上データを入れ、

商品A
3個 + 7個 = 10個

商品B
5個

という状態を作ります。

そのうえで、

/api/dashboard-data?year=2026&month=8

へアクセスし、

商品A：10
商品B：5

という結果になることをpytestで確認しました。

さらに、

ranked_sales
chart_labels
chart_values

の順番と数量が一致することも確認しています。

販売終了した商品の過去売上も集計対象として残り、

フィルタを付けなければ、

全期間

の売上が集計されることもテストしました。

このダッシュボードAPIの4件は、追加した時点からすべて成功しました。

つまりここでも、

現在すでに正しく動いている集計仕様を、将来壊さないためにテストへ残した

形です。

また、このAPIのテストではGemini Clientを呼び出さないことも前提にし、DB集計部分を外部APIから切り離して確認しています。

9件から51件へ

第1段階終了時点では、

9 passed

でした。

第2段階終了時点では、

51 passed

になりました。

ただし、

51件あるから安全

という意味ではありません。

pytestは、テストとして書いた内容しか確認できません。

今回も作業中に、

同じ商品名を持つ別Product IDをどのように集計するか
商品名の文字数制限
yearの許容範囲
同数量商品のランキング順
売上0件時のAPI仕様

など、まだ仕様を決めていない項目が見つかっています。

これらについては、

仕様が決まっていないままCodexに判断させて修正範囲を広げることはしませんでした。

今回の作業範囲から外し、未対応事項として残しています。

テスト件数そのものより、

どんな事故を防ぐためのテストなのか

を把握しておく方が大切だと感じました。

今回やってみて分かったこと

今回の第2段階では、最初から大きなテスト計画を完璧に作っていたわけではありません。

一つ確認すると、

「では、この場合は？」

という穴が見つかり、またテストを追加する。

その繰り返しでした。

結果として、

入力値
↓
商品確認
↓
DB保存
↓
失敗時rollback
↓
履歴保持
↓
集計

まで確認することになりました。

トラックの仕事で考えると、

「事故を起こさないよう注意する」

だけではなく、

危険な荷物は積ませない
積み方がおかしければ出発させない
問題が起きたら途中で止める
過去の記録を残す
最後に結果を確認する

という仕組みを作る感覚に近い気がします。

まとめ

今回のpytest強化第2段階では、

売上POSTの全件事前検証
商品の存在・年月・販売状態確認
(product_id, date)のDB一意制約
Alembicマイグレーション
隔離PostgreSQLでのupgrade / downgrade確認
売上POSTのrollback
商品POSTの17種類の不正入力検証
商品POSTのrollback
論理削除と過去売上履歴の保持
dashboard APIのDB集計

まで確認しました。

pytest全体は、

9 passed
↓
51 passed

となりました。

今回改めて感じたのは、

「同じミスをしないよう気をつける」より、同じ危険な状態になったら自動で止まる仕組みを作る方が再発防止になる

ということです。

一方で、まだ仕様を決めていない項目や、今回扱っていない領域もあります。

次の段階では、認証・認可・CSRFなど、

「誰がその操作をしてよいのか」

という部分を確認していく予定です。

pytestを「事故防止台帳」として育てる作業は、もう少し続きそうです。