追記
この記事は、pytestを3件から9件へ強化した時点で、自分なりにpytest・GitHub Actions・CIの関係を整理した記録です。
その後も「pytestを事故防止台帳として育てる」という考え方を継続し、売上入力・商品登録・DB制約・rollback・履歴保持・ダッシュボード集計などへ回帰テストの範囲を広げています。
そのため、本文中の「9件」や「今後テストしたい領域」は、この記事執筆時点の状態としてお読みください。
はじめに
私は現在、本業でトラックドライバーとして働きながら、PythonやFlaskを使ったWebアプリケーション開発を独学しています。
この記事を書いた時点での累計学習時間は159時間でした。
当時、個人開発中のアプリで、
- XSS対策
- データベースのマイグレーション修正
- pytestの強化
- GitHub Actionsによる自動テスト
などを進めていました。
ただ、自分自身も学び始めたばかりなので、
「pytestって結局何をしているの？」
「GitHub Actionsとpytestは何が違うの？」
「CIって急に出てきたけど何者？」
と、一つずつ確認しながら進めています。
そこで今回は、当時自分がやっていたことを、
普段の仕事で使っている「点検簿」や安全管理
にたとえながら、初心者なりに整理してみます。
まず、今やっていることを一言でいうと
当時の開発では、次のような流れを作り始めていました。
不具合・ヒヤリハットを発見
↓
原因を確認
↓
コードを修正
↓
pytestへ再発防止テストを追加
↓
GitHubへpush
↓
GitHub Actionsがpytestを自動実行
↓
問題が戻っていればCIが失敗する
最初は、
「pytestを書いている」
くらいの認識でした。
しかし実際には、
過去に見つけた不具合を記録し、同じ危険な状態へ戻ったら自動的に気付ける仕組み
を作っているのだと分かってきました。
pytestとは？
pytestは、Pythonでテストを書くためのツールです。
ものすごく簡単に言えば、
「このプログラムは今も想定どおり動いているか？」を自動で確認するもの
です。
例えば足し算をする関数なら、
def add(a, b):
return a + b
に対して、
def test_add():
assert add(2, 3) == 5
というテストを書けます。
assertは、
「この結果になるはず」
という確認です。
結果が想定どおりなら成功します。
PASSED
違っていれば失敗します。
FAILED
トラックで考えると「点検項目」に近い
トラックには出庫前点検があります。
例えば、
□ タイヤに異常はないか
□ ランプは点灯するか
□ オイルに問題はないか
□ ブレーキに異常はないか
と確認します。
pytestも似ています。
システムなら、
□ AIへの指示文が壊れていないか
□ HTMLが危険な形で表示されていないか
□ 商品データが正しく処理されるか
□ 売上データが意図しない状態になっていないか
といった確認ができます。
つまり自分の中では、
pytestのテスト1件 = 点検項目1個
くらいのイメージになりました。
テストコードは「点検簿」
さらに複数のpytestが集まると、
自分には「点検簿」のように見えてきました。
この記事を書いた時点では、自分のアプリのpytestを3件から9件へ増やしました。
ただし、単純に件数を増やしたわけではありません。
例えば以前、
AI返答をJavaScriptのinnerHTMLで表示していた箇所がありました。
その問題を修正したあと、
将来また同じ危険な表示方法へ戻っていないか
を確認するpytestを追加しました。
つまり、
XSSの危険を発見
↓
修正
↓
その修正内容をpytestへ残す
という流れです。
これなら半年後に自分が忘れていても、
pytestが確認項目として残してくれます。
その後も、この考え方を使ってテスト範囲を少しずつ広げています。
「次から気をつける」だけでは再発防止にならない
普段の仕事でも、事故やミスが起きたあと、
次から気をつけます
だけでは弱いと感じます。
それだけなら、人の注意力に再び頼ることになります。
大切なのは、
二度と同じことをしないこと
だけではありません。
自分は、
二度と同じ危険な状況・状態にならないようにすること
の方が重要だと考えています。
例えば配送中に、
「毎回同じ時間帯に、ある場所で危険な状況になる」
のであれば、
もっと注意して運転する
だけではなく、
配送時間を変更する
配送順を変更する
別ルートを使う
など、
危険な状況そのものを作らない方法を考えます。
システムも同じでした。
XSSを例にすると分かりやすい
以前のアプリでは、AIから返ってきた文章を、
innerHTML
で表示していました。
ここで、
危険なHTMLを入力しないように気をつける
だけでは弱いです。
そこで、
HTML風の文字列が来ても、
HTMLとして解釈されない表示方法にする
ように修正しました。
さらにpytestへ、
以前の危険な表示方法へ戻っていないか
という点検項目も追加しました。
これで、
注意する
から、
危険な状態を仕組みで防ぐ
へ変わります。
ではGitHub Actionsとは？
ここで最初、自分は少し混乱しました。
pytestを実行するときは、
pytest -v
というコマンドを自分で打ちます。
ではGitHub Actionsは何をするのか？
自分のリポジトリでは、
GitHubへコードをpushすると、
GitHub側の環境で自動的にpytestを実行する
よう設定しています。
例えば、
git push origin main
すると、
GitHub Actions起動
↓
Python環境を準備
↓
必要なライブラリをインストール
↓
pytest -v
↓
結果を確認
という処理が自動で動きます。
現在の設定では、mainへのpushに加えて、main向けのPull Requestでもテストが実行されます。
出庫前点検と出荷ゲート
これもトラックに例えると、自分には分かりやすくなりました。
ローカルPCで、
pytest -v
を実行するのは、
自分で行う出庫前点検
のようなものです。
そしてGitHubへpushすると、
GitHub Actionsがもう一度pytestを実行します。
これは、
出荷ゲートでもう一度自動点検される
イメージです。
開発者
「自分で点検しました」
↓
push
↓
GitHub Actions
「こちらでも点検します」
↓
tests passed
↓
OK
ローカルだけではなく、GitHub側の環境でも確認できるのがポイントです。
CIって何？
そして、ここで登場するのが、
CI
です。
正式には、
Continuous Integration
と呼ばれます。
日本語では「継続的インテグレーション」などと訳されます。
ただ、初心者の自分には最初、
「それで結局何をするの？」
という感じでした。
自分の現在の開発に当てはめてかなり簡単に言えば、
コードの変更をGitHubへ反映したときに、自動テストを実行して問題がないか確認する仕組み
と考えると理解しやすかったです。
厳密にはCIにはテスト以外の処理を組み込む場合もありますが、
自分のリポジトリではGitHub Actionsでpytestを自動実行することが、CIの中心になっています。
pytestとGitHub ActionsとCIの違い
自分なりに整理すると、こうなります。
| 名前 | 自分なりの理解 |
|---|---|
| pytest | 点検するための道具 |
| pytestのテスト | 点検項目 |
| テストファイル | 点検簿 |
| GitHub Actions | 点検を自動実行する設備 |
| CI | コード変更を継続的に自動確認する運用 |
この違いが分かると、一気に整理できました。
実際のGitHub Actions設定
自分のリポジトリでは、GitHub Actionsで次のような構成にしています。
主要部分を抜き出すと、
on:
push:
branches: [ main ]
pull_request:
branches: [ main ]
jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-python@v5
with:
python-version: '3.12'
- run: pip install -r requirements.txt
- run: pytest -v
mainブランチへのpushや、main向けのPull Requestをきっかけに、
GitHub Actionsがpytestを実行します。
以前は、
pytest test_prompts.py -v
となっていました。
これでは特定のテストファイルしか実行されません。
そこで、
pytest -v
へ変更しました。
これにより、pytestの通常の収集ルールに従って、新しく追加したテストもCIで実行されるようになりました。
なぜこれが便利なのか
例えば今後、別の機能を修正したとします。
その修正自体は正常に動いていても、
知らないうちに以前直したXSS対策を壊してしまう可能性があります。
人間が毎回、
XSS大丈夫
プロンプト大丈夫
Jinja大丈夫
Gemini大丈夫
売上大丈夫
DB大丈夫
と全部覚えて確認するのは大変です。
そこでpytestへ点検項目を残しておけば、
pytestに確認させる
ことができます。
さらにGitHub Actionsを使えば、
ローカルでpytestを実行し忘れた
場合でも、GitHub側で自動確認されます。
もちろん、GitHub Actionsがあるからローカル確認をしなくてよいという意味ではありません。
自分の中では、
ローカルpytest = 出庫前点検
GitHub Actions = 出荷ゲートでの自動点検
という二段階で考えています。
小さなヒヤリハットをテストに変える
この記事を書いた時点では、
小さな不具合を発見
↓
原因を確認
↓
修正
↓
再発防止テストを書く
↓
GitHub Actionsで毎回確認
という流れを続けようと考えていました。
自分の中では、
pytestを「事故防止台帳」として育てる
というイメージです。
新しい問題を見つけるたびに、
点検簿の項目が一つ増えていきます。
その後もこの方針を続け、
売上入力や商品登録など、DBを変更する処理についても、
HTTPレスポンスだけを見る
のではなく、
失敗後にDBがどうなっているかまで確認する
テストへ広げています。
もちろんpytestだけで安全になるわけではない
ここは注意したいところです。
この記事執筆時点でpytestが9件になったから、
このシステムは安全！
とは言えません。
テストされていない場所はまだたくさんありました。
当時、今後確認したい領域として、
- PostgreSQLのマイグレーション
- 認証
- CSRF
- 不正な売上入力
- Gemini API障害
- 実ブラウザでのDOM動作
などを考えていました。
その後、
不正な売上入力・商品登録・DB一意制約・rollback・論理削除後の履歴保持・ダッシュボード集計などについては、回帰テストの範囲を広げています。
一方で、
認証・認可・CSRFなど、別段階で扱う予定の領域も残っています。
点検簿があるから事故が絶対に起きないわけではないのと同じです。
それでも、
一度見つけた危険を、同じ形で見逃しにくくする
ためには大きな意味があると感じています。
おわりに
プログラミングを始めた頃の自分に、
pytest
GitHub Actions
CI
回帰テスト
と言われても、
おそらくよく分からなかったと思います。
しかし、自分の普段の仕事に置き換えてみると、
pytest
= 点検
テストコード
= 点検簿
GitHub Actions
= 自動点検設備
CI
= コード変更を継続的に自動確認する仕組み
と考えられるようになりました。
そして現在は、
発見
↓
原因確認
↓
修正
↓
pytestへ再発防止ルールを追加
↓
ローカルで確認
↓
push
↓
GitHub Actionsが自動点検
という流れで開発しています。
この記事を書いた時点ではpytestは9件でしたが、
その後も実際に見つかった不具合や守りたい仕様を追加し、
「正常確認の道具」ではなく、「過去のヒヤリハットを残す事故防止台帳」
として検証範囲を広げています。
まだ学習途中ですが、
分からない専門用語をそのまま覚えるのではなく、
「つまり何をしているのか？」まで自分の言葉に置き換えること
も、学習の一つなのだと思います。