Pytestとは｜使い方・fixture・unittestとの違いと案件単価【pytest 9対応】
最終更新日：2026/10/19
Pytestとは、Pythonのテストを書いて実行・管理するオープンソースのテストフレームワークです。標準のunittestより少ないコードで書け、2024年の開発者調査では回答者の53%が使っていました。2025年11月の9系でPython 3.10以上が必要になりました。テストを担うエンジニア向けに、使い方から案件での評価まで整理します。
先に結論
Pytestは、主要な開発者調査でPythonのテストフレームワークとして最も多く使われている。Python Software FoundationとJetBrainsの2024年調査（回答者3万人超・複数回答）では、単体テストフレームワークの利用率がpytest 53%、標準のunittest 23%だった
標準のunittestとの最大の違いは、クラスを継承せず関数とassert文だけで書けること。unittestで書かれた既存のテストもそのまま実行できる
2026年10月時点の最新はpytest 9.1.1。9.0（2025年11月）でPython 3.9のサポートが終了し、subtestsの本体統合、TOML形式の設定ファイル、strictモードが加わった。8系前提の解説記事は設定の書き方が古い場合がある
現場で「テストが書ける人」と見なされる分岐点は、fixtureとparametrizeを使い分けられるか
フリコン掲載のPython案件3,760件のうち、案件名や概要にPytestを明記した案件は5件（0.13%）だけ。Pytestは看板スキルではなく、テストの担当範囲の中で評価されるスキル
単価との関係が見えるのは、ツール名より担当範囲。概要に「品質」「自動化」「CI」などの語がある案件は上限100万円以上が18.8%、「テスト」が工程名としてだけ出る案件は6.5%だった
この記事でわかること
Pytestの定義と、Pythonのテストツールの中での位置づけ
unittest・nose2・doctestとの違いと、選び分けの考え方
pytest 9で変わった点（Python 3.10以上・subtests・TOML設定・strictモード）
fixture・parametrize・marker・pluginなど、実務でよく使う機能
フリコン掲載のPython案件3,760件から見た、テストの担当範囲と単価の関係
本記事は、Pythonの実務経験があり、テストの書き方を固めたいエンジニアと、Python案件で独立・参画を考えているフリーランスエンジニアを主な読者として書いています。
目次
Pytestとは？Pythonテストの定番フレームワーク
pytest 9で変わった点
Pytestとunittest・その他テストツールとの違い
Pytestでできること（実務での使われ方）
Pytestの始め方（インストールから初回実行まで）
Pytestの主要機能（フリーランス現場でよく使うもの）
Pytestを使うフリーランス案件の単価相場と動向
Pytestの学習ロードマップ
Pytestを案件で活かすためのキャリア戦略
テスト関連の記事マップ（言語・ツール・職種）
よくある失敗と対策
案件参画前に確認したいPytest関連のチェックポイント
まとめ
よくある質問
Pytestとは？Pythonテストの定番フレームワーク
Pytestとは、Pythonのコードに対するテストを記述・実行・管理するためのサードパーティ製のテストフレームワークです。 標準ライブラリには含まれず、pipでインストールして使います。ライセンスはMITで、商用でも無料で使えます。
Pytest公式ドキュメントによれば、最小構成のテストは「test_」で始まる関数を作り、assert文で条件を書くだけで実行できます。クラスの継承や特別なメソッド名は必須ではないため、初めてでも書き始めやすい設計です。
Pytestの基本的な特徴
Pytestには、現場で評価されている特徴がいくつかあります。
assert文がそのまま使える：unittestのassertEqualやassertTrueといった専用メソッドを覚える必要がない
失敗時の出力が読みやすい：assertが失敗すると、比較した値の中身を整形して表示する
fixtureで前処理・後処理を共通化できる：setUp/tearDownより柔軟に組める
parametrizeで同じテストを複数データで回せる：データ駆動のテストが簡潔に書ける
プラグインが豊富：pytest-mock、pytest-django、pytest-asyncioなど、用途別の拡張がそろう
どれくらい使われているか
Python Software FoundationとJetBrainsが2024年10〜11月に実施したPython Developers Survey 2024（回答者3万人超）では、単体テストフレームワークの利用率は次のとおりでした（複数回答）。
テストフレームワーク | 利用率 |
|---|---|
pytest | 53% |
unittest | 23% |
mock | 11% |
doctest | 6% |
テストフレームワークを使っていない | 36% |
pytestの利用率はunittestの2倍以上です。一方で、回答者の36%はテストフレームワークを使っていません。テストを書く習慣自体が、まだ全員のものではないことも読み取れます。
なぜPytestが選ばれるのか
Pythonには標準ライブラリのunittestがあるため、本来は別のフレームワークを入れなくてもテストは書けます。それでもPytestが選ばれるのは、テストを書く負担を減らす設計だからです。
unittestがJavaのJUnitを手本にしているのに対し、Pytestは「Pythonらしい書き方」を重視しています。関数だけで書ける、assert文がそのまま動く、fixtureを関数の引数として受け取れる——こうした書き方は、テストコードを読み書きする時間を短くします。新しくテストを導入するPythonのプロジェクトでは、Pytestが第一候補として検討されることが多いです。
なお、JavaのテストではJUnitが広く使われています。JavaからPythonに移る場合は、JUnitの感覚を持ち込むより、Pytest独自の書き方を学び直すほうがスムーズです。
ミニFAQ：どのバージョンのPytestを学べばよい？
2026年10月1日時点の最新はpytest 9.1.1（2026年6月19日リリース）で、Python 3.10以上が必要です（PyPIのpytestページ）。新しく学ぶなら9系で問題ありません。参画先の現場が8系以前を使っている場合もあるため、requirementsやpyproject.tomlで実際のバージョンを確認しておきましょう。
pytest 9で変わった点
pytest 9.0は2025年11月にリリースされた、2024年1月の8.0以来のメジャーバージョンです。 公式のChangelogから、実務に影響しやすい変更を整理します。
変更点 | 内容 | 実務への影響 |
|---|---|---|
Python 3.9のサポート終了 | 9系はPython 3.10以上が必要 | 古いPythonの現場では8系のまま止まっていることがある |
subtestsの本体統合 | pytest-subtestsプラグインの機能が本体に入った | 収集時に値が決まらないケースを1つのテストの中で分けて検証できる（機能は実験的扱い） |
TOML形式の設定 | pyproject.tomlの[tool.pytest]や、pytest.tomlで設定を書ける | 従来の[tool.pytest.ini_options]も使えるが、新規はTOML形式が書きやすい |
strictモード | strictをtrueにすると、strict_config・strict_markers・strict_parametrization_ids・strict_xfailの4つがまとめて有効になる（個別に上書きも可） | 設定ミスやマーカーの打ち間違いをCIで早く見つけられる |
非推奨機能のエラー化 | PytestRemovedIn9Warningが既定でエラーになった | 古いプラグインや書き方が残る現場では、更新で突然テストが落ちることがある |
設定ファイルの具体的な書き方は、使うバージョンの公式ドキュメント（Configuration）で確認してください。9.1（2026年6月）ではPython 3.15の公式サポートが加わりました。一方で、いくつかの機能が非推奨になり、pytest 10で削除する予定と告知されています。
ミニFAQ：8系の現場に入ったら、9系との違いで困る？
テストの書き方そのもの（関数、assert、fixture、parametrize）は変わっていないため、大きく困ることはありません。違いが出るのは設定ファイルの書き方と、非推奨警告の扱いです。バージョンを上げる作業を任されたら、まず警告を一覧にして、どのプラグインが原因かを切り分けるところから始めると安全です。
Pytestとunittest・その他テストツールとの違い
Pythonのテストツールには、Pytest以外にも選択肢があります。違いを押さえておくと、技術の選定や案件参画時の判断がしやすくなります。
ツール | 位置づけ | 特徴 |
|---|---|---|
unittest | Python標準ライブラリ | クラスベース。JUnitに近い書き方。追加のインストールが不要 |
Pytest | サードパーティ（MITライセンス） | 関数ベース。assert文をそのまま使える。fixture・parametrizeが強力 |
nose2 | サードパーティ | 旧noseの後継。利用は限られる |
doctest | Python標準ライブラリ | docstringに書いた実行例をテストとして実行する |
unittestとの違い
unittestは標準ライブラリなので、追加の導入が要らないのが利点です。一方のPytestは、unittestで書かれたテストもそのまま実行できる互換性を持っています。
既存のunittest資産がある現場では、まずPytestを実行ツール（テストランナー）として導入し、新しいテストはPytestの書き方で足していく移行がよく採られます。pytest 9.0の変更履歴によると、unittestのsubTestも本体で扱えるようになりました。subTestを使った既存テストを移行するときの手間は、以前より小さくなっています。
nose・nose2の現在地
かつてはnoseがPytestと並ぶ選択肢でしたが、オリジナルのnoseは長くメンテナンスされておらず、新しいPythonでは使えない場面があります。後継のnose2は維持されているものの、前述の調査でnoseを使うと答えたのは2%でした。古い保守案件でnose系のテストが残っている場合は、Pytestへの移行計画があるかを参画前に確認すると安全です。
Pytestとunittestの選び分け
選び分けの目安は次のとおりです。
新規プロジェクト：Pytestを採用するケースが多い
依存を増やせない小さなスクリプトのテスト：標準のunittestで足りる
テストデータが多い／前処理が複雑：Pytestのfixtureとparametrizeで簡潔に書ける
JUnit経験者が多いチーム：unittestのクラスベースのほうが読みやすい場合もある
Pytestでできること（実務での使われ方）
Pytestは単体テストだけのツールではなく、統合テストやE2Eテストの実行役としても使われます。 実務での使われ方をレイヤーごとに見ていきます。
ユニットテスト
関数やクラスのメソッドの入出力を検証する、最も基本的な使い方です。fixtureで前提条件を組み立て、parametrizeで境界値を網羅する流れが定番です。
統合テスト
複数のモジュールを組み合わせた動作を確認するテストです。WebアプリならDBやキャッシュを含めた挙動、データ処理パイプラインなら入力ファイルから出力までの一連の流れを確かめます。pytest-djangoやpytest-flaskといった統合用のプラグインがあり、Django・Flask・FastAPIの現場でもよく使われます。
E2E（End to End）テスト
ブラウザ操作を含むE2Eテストは、PytestとSelenium・Playwrightを組み合わせて作ります。実行の管理はPytestに任せ、画面操作はPlaywrightやSeleniumに任せる分担が一般的です。Playwrightには公式のPytestプラグイン（pytest-playwright）があります。
CI/CDパイプラインへの統合
PytestはGitHub ActionsやJenkinsと組み合わせやすく、プルリクエストごとに自動でテストを回す運用が組みやすいのも評価されている点です。JUnit形式のXMLレポートを出力するオプションがあり、CIツール側の集計と相性が良い作りになっています。
ミニFAQ：Pytestはデータ分析や機械学習のコードでも使う？
使います。pandasやNumPyを使う処理のロジック、機械学習モデルの前処理関数などのテストに使われます。データ系の現場ではテストが整っていないコードベースも多く、テストを書ける人が重宝されやすい領域です。
Pytestの始め方（インストールから初回実行まで）
Pythonと仮想環境の扱いに慣れていれば、インストールから最初の実行までは短時間で終わります。
環境準備
Python公式サイトからPython本体（pytest 9系を使うなら3.10以上）を入れ、venvなどで仮想環境を作ります。仮想環境の中でpip install pytestを実行すれば、インストールは完了です。テスト用の依存はrequirementsファイルやpyproject.tomlにまとめておくと、CI環境で同じ状態を再現しやすくなります。
最初のテストを書く
プロジェクト直下か、testsディレクトリに、名前が「test_」で始まるPythonファイル（例：tests/test_calc.py）を作ります。その中に「test_」で始まる関数を定義し、assert文で期待値を書きます。たとえば足し算の関数をテストするなら、テスト関数の中でその関数を呼び出し、結果が期待した値と等しいことをassertで宣言します。
実行と結果の見方
ターミナルでpytestコマンドを実行すると、テストファイルが自動で見つかり、まとめて実行されます。失敗したときは、assertが失敗した箇所と比較した値が整形されて表示されます。原因の特定が早いことが、初めて使う人に好評な理由のひとつです。
Pytestの主要機能（フリーランス現場でよく使うもの）
現場で頻出するのは、fixture・parametrize・marker・pluginの4つです。 これらを押さえておくと、参画初日からテストを書く側に回りやすくなります。
fixture（前処理・後処理の共通化）
fixtureは、テストの前に共通で用意したいもの（DBセッション、設定、テストデータなど）を関数として定義し、必要なテストの引数として受け取る仕組みです。conftest.pyにfixtureをまとめると、複数のテストファイルから自動で参照されます。
unittestのsetUp/tearDownと比べると、fixtureは有効範囲（スコープ）をfunction／class／module／package／sessionから選べ、必要な箇所だけで呼び出せるのが利点です。たとえばDB接続をテスト全体で使い回したいなら、scopeにsessionを指定すると、毎回接続し直すコストを抑えられます。
parametrize（テストデータのバリエーション）
pytest.mark.parametrizeを使うと、同じテストのロジックを複数の入力データで自動的に繰り返せます。境界値テスト、異常系テスト、ロケール別のテストなどを簡潔に書けます。ケースが増えても、テスト本体のコードを増やさずに済むのが大きな利点です。
marker（テストの分類・条件付き実行）
markerは、テストにタグを付けて分類する仕組みです。重いテストにslowマーカーを付けておき、普段のCIではslow以外だけを、夜間ビルドでは全部を実行する、といった運用ができます。skipやskipifを使えば、条件に応じてテストを飛ばせます。pytest 9のstrictモードを有効にすると、登録していないマーカーの打ち間違いもエラーで見つかります。
plugin（pytest-mock、pytest-cov、pytest-xdistなど）
Pytestはプラグインで拡張する文化が強く、現場では次のものがよく使われます。
pytest-mock：標準のunittest.mockをPytestの書き方で使えるようにする
pytest-cov：テストのカバレッジ（どのコードがテストで実行されたか）を計測する
pytest-xdist：テストを複数のプロセスで並列に実行し、時間を短くする
pytest-django：Djangoプロジェクト向けの機能を提供する
pytest-asyncio：async/awaitを使うコードのテストを書けるようにする
これらは本体ではなく、サードパーティの実績あるプラグインです。なお、以前はpytest-subtestsプラグインが必要だったsubtestsは、9系から本体の機能になりました。参画先のrequirementsに何が入っているかを見ると、その現場のテストの方針が読み取れます。
ミニFAQ：fixtureを増やしすぎるとどうなる？
fixtureの数が多かったり、fixture同士の依存が深くなったりすると、テストが読みにくくなります。「このテストで何が準備されているのか」を追うのに時間がかかり、保守の負担が増えます。conftest.pyに置くのは複数のテストで本当に共通化が必要なものに絞り、1回しか使わない準備はテスト関数の中に書くのが現場でよく取られる判断です。
Pytestを使うフリーランス案件の単価相場と動向
Pytestは、案件の看板としてはほとんど書かれないスキルです。 ここでは、フリコンに掲載されているPython案件3,760件（2026年10月1日時点・募集終了の案件を含む）の一覧カードに表示される、案件名・技術タグ・案件概要（抜粋）をすべて確認した結果をもとに整理します。単価は掲載時の募集単価の上限で、成約単価ではありません。
Pytestを明記した案件は0.13%
3,760件のうち、案件名か概要の抜粋に「pytest」の文字がある案件は5件でした。中身はFastAPIでのWebAPI開発、Flaskの製品開発、Playwrightを使った自動テスト基盤づくりなどで、いずれも開発の一部としてPytestでテストを書く形です。
一方で、「テスト」という語を含む案件は746件（19.8%）ありました。Pytestは案件名で探すスキルではなく、「テストまで任せられるか」という担当範囲の中で問われるスキルと捉えるのが実態に近いでしょう。
担当範囲で見た単価の傾向
概要の書かれ方で3つに分けると、募集単価の上限は次のようになりました。
概要の書かれ方 | 案件数 | 上限の平均 | 上限90万円以上 | 上限100万円以上 |
|---|---|---|---|---|
「品質」「自動化」「CI」「テスト設計」などの語がある | 165件 | 84.0万円 | 31.5% | 18.8% |
「テスト」が工程名としてだけ出る（単体テスト・結合テストなど） | 680件 | 78.1万円 | 20.3% | 6.5% |
テスト関連の語がない | 2,915件 | 81.4万円 | 30.1% | 13.3% |
Python案件全体 | 3,760件 | 80.9万円 | 28.4% | 12.3% |
出典：Pythonのフリーランス案件・求人一覧（フリコン）のカード表示をもとに当社集計。
「製造〜単体テスト〜結合テスト」のようにテストが工程の一部として並ぶ案件は、上限100万円以上の比率が全体の約半分にとどまりました。反対に、品質の改善や自動化、CIまで任せる書き方の案件は、比率が全体より高くなっています。
ただし、これは案件カードの短い抜粋をキーワードで分けた集計です。165件は多い数ではなく、職種の構成も違うため、「品質」と書けば単価が上がるという因果を示すものではありません。 読み取れるのは、テストを「実施する」担当より、テストの仕組みを「設計・改善する」担当のほうが、高い帯の募集に入りやすいという傾向までです。
テスト専任の職種との比較
テストを専門に担う職種で見ると、傾向はさらにはっきりします。フリコンのテストエンジニアの案件（1,219件・職種タグで集計）は、上限の平均が64万円、上限100万円以上が2.0%でした。
上の表はPythonのスキルタグ、こちらは職種タグでの集計です。集計の単位が違うため、数字を直接比べることはできません。それでも、テストだけを担う働き方より、Pythonで開発しながらテストの仕組みまで整える働き方のほうが、高い帯の募集に届きやすいことがうかがえます。職種としての詳しい動向はテストエンジニアとはで解説しています。
案件で求められるレベル感
Pytestについて案件で求められる水準は、大きく3段階に分けられます。
入門：既存テストの実行・修正、簡単なテストの追加ができる
中級：fixture・parametrize・markerを使い分け、新しいモジュールのテストを設計できる
上級：テストの方針を立て、CI/CDに組み込み、カバレッジの運用やテストの分割で開発サイクル全体を速くできる
上限90万円を超える帯に入りやすいのは、上級の内容を担える人です。目安としては、Pythonの実務が複数年あり、テストの方針づくりやCIの整備、レビュー方針の策定まで経験している層になります。
単価を体系的に上げる考え方は『フリーランスエンジニアの単価相場と単価の上げ方』で整理しています。自分の経験でどのくらいの単価を狙えるか気になる方は、無料のフリーランスエンジニア単価診断で市場単価の目安を確認できます。
Pytestスキルが評価される場面
Pytestは単価を直接上げるスキルというより、参画後に任される仕事の幅を広げるスキルです。評価されやすいのは次のような場面です。
テストが薄い既存コードに、後からテストを書いていく品質改善
新規プロジェクトで、テストの方針を最初から設計する立ち上げ
プルリクエストにテストを付けて出すことによる、レビューでの信頼
GitHub Actionsなどでの自動実行の設定まで含めたCI/CDの整備
Pytestの学習ロードマップ
初めて触る段階から、実務で使える水準に届くまでの順番を整理します。
初心者がまず押さえること
最初に取り組むのは次の3点です。
pip install pytestから最初のテスト実行までを自力でできる
assert文の基本パターン（等しいか、近い値か、例外が出るか、コレクションの中身）を書ける
fixtureの最小例（値を返す関数を引数として受け取る形）を動かせる
ここまで身につけば、自分が書いたコードに簡単なテストを付けられるようになります。
中級レベルへのステップ
中級では、現場でよく見るパターンへの対応力が問われます。
conftest.pyを使ったfixtureの共有
parametrizeでの境界値テスト・異常系テストの設計
markerによるテストの分類と、strictモードでの管理
pytest-covによるカバレッジ計測の基本
pytest-mockによる外部依存（API呼び出し、DBなど）の置き換え
このあたりまで来ると、新しいモジュールのテストを任されても自走できる水準です。
学習リソース
公式ドキュメントを軸に、技術書やオンライン教材を組み合わせるのが定番です。
公式のGet Started、Fixtures、Parametrizing testsのページが基本
英語が苦にならなければ、公式のExamples and customization tricksが実務寄り
書籍やWeb記事は、pytest 9より前に書かれたものだと設定ファイルの書き方が古い場合がある
Python本体の理解が浅い場合は、先にPythonとは？できること、将来性、年収・キャリアまで徹底解説！で全体像をつかんでからPytestに進むと、学習の効率が上がります。テストを先に書いて開発を進める手法は、TDD（テスト駆動開発）とはで整理しています。
ミニFAQ：学習時間の目安はどのくらい？
個人差が大きいものの、Pythonの基礎ができている人なら、入門の範囲は短期間で押さえられる傾向があります。中級（fixture・parametrize・marker・カバレッジを使い分けられる）に届くには、実際のプロジェクトで使いながら経験を積む必要があります。机の上の学習だけで仕上げるより、個人開発や業務のコードで使いながら覚えるのが現場では一般的です。
Pytestを案件で活かすためのキャリア戦略
Pytestを単独のスキルとして売るのではなく、ほかのスキルと組み合わせて案件の幅を広げるのが現実的です。 案件のデータでも、テストの仕組みまで任される書き方の案件ほど、高い帯の募集が多く見られました。
テスト自動化の案件で重宝されるスキル
テスト自動化を中心に参画する場合、Pytestに加えて次のスキルがあると評価されやすくなります。
E2EテストのSeleniumまたはPlaywrightの経験
テストの方針を立てた経験（テストピラミッド、テストの分割の判断）
カバレッジツールの運用経験
品質保証の立場から関わる働き方は、QAエンジニアとはも参考になります。
Web開発エンジニアとしての組み合わせ
Django・Flask・FastAPIの案件では、Pytestが使えることが「テストまで含めて任せられるエンジニア」の条件になりつつあります。
データ・機械学習領域での価値
データ分析・機械学習の現場では、テストの薄いコードベースが残っているケースが少なくありません。データ系の知見とテスト自動化の両方を持つ人は、品質改善の文脈で頼られやすくなります。データ前処理の関数のテストや、モデルの推論結果が変わっていないかを確かめるテスト（リグレッションテスト）が代表例です。
どの案件タイプを目指すかの決め方は、案件の選び方｜フリーランスエンジニアが単価・稼働・スキルで決める優先順位で整理しています。
テスト関連の記事マップ（言語・ツール・職種）
Pytestと一緒に検討されることが多いテストの技術と職種を、目的別にまとめました。
知りたいこと | 記事 |
|---|---|
ほかの言語のテストフレームワーク | |
ブラウザを使うE2Eテスト | |
テストを自動で回すCI/CD | |
テストの進め方と生成AIの活用 | |
テストを担う職種 |
よくある失敗と対策
Pytestの導入や運用で陥りやすいパターンを整理します。
fixtureの共通化しすぎ
fixtureを共通化しすぎると、conftest.pyが膨らみ、各テストでどのfixtureが効いているのかを追えなくなります。「同じ準備を2回以上書きそうになったら共通化する」くらいの温度感で進め、1回きりの準備は関数の中に書くのが無難です。
テストが遅くなる
テストが増えると、実行時間が問題になります。典型的な原因は、DBへの接続を毎回張り直している、大きなデータを毎回読み込んでいる、外部APIを実際に呼んでいる、の3つです。fixtureのスコープを見直す、モックを使う、pytest-xdistで並列に実行する、といった対応が効きます。
ローカルでは通るのにCIで落ちる
この多くは、テストの実行順への依存（あるテストが別のテストの結果に頼っている）、環境変数の違い、タイムゾーンの違いが原因です。テスト同士を独立させる、CIと同じコンテナイメージでローカルでも実行する、といった対策が効きます。
バージョンを上げたら大量に落ちた
pytest 9では、9系で削除予定だった機能の警告が既定でエラーになりました。古いプラグインや書き方が残る現場でバージョンだけ上げると、テストのロジックは正しいのに一斉に失敗することがあります。上げる前に8系のまま警告を一覧にし、原因のプラグインを先に更新するのが安全な順番です。
テストを書く時間が取れない
「テストを書く時間がない」という声は多くの現場で聞かれます。ただ実際には、テストがないことで生まれるバグ対応や手動確認の時間が、テストを書く時間を上回っていることも少なくありません。まずは新しく追加するコードにだけテストを書くルールから始めると、既存のコード全部に書く負担を背負わずに自動化を進められます。
案件参画前に確認したいPytest関連のチェックポイント
参画先のテスト運用は、面談や事前の資料で確認しておくと、参画後の負担を読みやすくなります。
確認項目 | チェック内容 |
|---|---|
テストの有無 | Pytest（または他のテストツール）が導入されているか |
バージョン | Python本体とPytest本体のバージョン。pytest 9系ならPython 3.10以上 |
カバレッジ | カバレッジを計測しているか、目標値があるか |
CI連携 | プルリクエストごとに自動でテストが実行されているか |
テストの方針 | テストを書く文化があるか、誰が書く前提か |
主要プラグイン | 使っているプラグインと、そのサポート状況 |
PythonやPytestのバージョンが極端に古い場合は、依存ライブラリの公式サポート切れ（EOL）も重なっていることがあります。保守案件で残っていても安全とは限らないため、アップデート計画の有無を確認しておきましょう。
まとめ
Pytestは、Python開発者の半数以上が使う定番のテストフレームワークで、案件では「テストまで任せられるか」を示すスキルとして評価されます。単価との関係が見えるのはツールの名前より担当範囲で、テストの仕組みを設計・改善できるほど高い帯の募集に届きやすくなります。
標準のunittestより、関数とassert文だけでシンプルに書ける。unittestのテストもそのまま実行できる
2026年10月時点の最新はpytest 9.1.1。9系はPython 3.10以上が必要で、subtests・TOML設定・strictモードが加わった
fixture・parametrize・marker・pluginを使い分けられると、現場の即戦力に近づく
フリコン掲載のPython案件3,760件で、Pytestを明記した案件は5件だけ。看板ではなく担当範囲の中で問われる
「品質」「自動化」「CI」まで任される書き方の案件は、上限100万円以上が18.8%（工程名だけの案件は6.5%）
学習は公式ドキュメントを軸に進め、9系より前の解説は設定の書き方に注意する
次の一歩としては、手元のプロジェクトに小さくPytestを入れ、GitHub Actionsなどで自動実行するところまで試してみてください。CIまでつないだ経験は、案件の面談で具体的に話せる材料になります。
参考リンク
よくある質問
Pytestは無料？商用利用に制限はある？
PytestはMITライセンスのオープンソースソフトウェアで、商用利用を含めて無料で使えます。ライセンスの表示などの条件を守れば、業務システムでも個人のプロジェクトでも使えます。
Pytestを使うなら、unittestの知識は不要？
必須ではありませんが、読めると役立ちます。Pytestはunittestで書かれたテストもそのまま実行できるため、移行途中の現場ではunittestの書き方が混ざっています。新規プロジェクトなら、最初からPytestの書き方で進めて問題ありません。
Pytestを覚えるとフリーランス案件の単価は上がる？
Pytestだけで単価が大きく上がるとは考えにくいです。フリコン掲載のPython案件で見ても、案件名や概要にPytestを明記した案件は3,760件中5件でした。単価との関係が見えるのは、テストの仕組みの設計や品質改善、CIの整備まで任される担当範囲のほうです。
PytestとSeleniumの関係は？
Pytestはテストを実行・管理する役、Seleniumはブラウザを操作するライブラリです。E2Eテストでは、Pytestで実行を管理し、その中でSeleniumを呼んでブラウザを操作する組み合わせがよく使われます。Playwrightと比べられるのはSelenium側で、どちらを選んでもPytestは実行役として使えます。
テストが増えて実行時間が長くなったら？
pytest-xdistで複数のプロセスに分けて並列に実行する、markerで分類して必要なものだけ実行する、fixtureのスコープを広げて準備のコストを下げる、外部APIや重い処理をモックに置き換える、といった方法があります。CIでは並列度を上げ、手元では変更した周辺だけを実行するなど、場面で使い分けましょう。
非同期コード（async/await）もテストできる？
本体だけでは非同期のテスト関数を直接扱えませんが、pytest-asyncioプラグインを入れるとasync関数をテストとして書けます。FastAPIなど非同期の処理を使うプロジェクトでよく採用されています。
PytestとJUnitの違いは？
どちらもテストフレームワークですが、JUnitはJava向け、PytestはPython向けです。設計の考え方も違い、JUnitはクラスベース、Pytestは関数ベースが基本です。JUnit経験者がPytestに移ると、クラスを継承せず関数だけで書けることが最初の発見になります。詳しくはJUnitとはも参照してください。
Pytestの設定ファイルはどこに書く？
pytest 9以降は、pyproject.tomlの[tool.pytest]テーブルか、pytest.tomlにTOML形式で書けます。従来のpytest.ini、pyproject.tomlの[tool.pytest.ini_options]、tox.ini、setup.cfgも引き続き使えます。新規プロジェクトでは、pyproject.tomlに集約するケースが増えています。
初めての人がPytestでつまずきやすいのはどこ？
fixtureの仕組みでつまずく人が多いです。「関数の引数にfixtureの名前を書くと、そのfixtureが返した値が渡される」というPytest独自の考え方に、最初は戸惑いやすいからです。公式ドキュメントのFixturesのページにあるサンプルを、そのまま書いて動かすところから始めると感覚をつかめます。
Pytestはこれからも主流であり続ける？
2024年の調査で利用率53%と、unittest（23%）の2倍以上で、Pythonのテストフレームワークでは最も使われています。2025年11月に9系が出て開発も続いており、短期間で別のフレームワークに置き換わる兆候は見られません。ただし設定の書き方などは変わっていくため、年に1回はリリースノートを確認する習慣をつけておくと安心です。
pytest 9はPython 3.9で使える？
使えません。pytest 9.0でPython 3.9のサポートが終了し、9系はPython 3.10以上が必要です。Python 3.9の環境が残っている場合は、8系のまま使うか、Pythonのバージョンを上げる計画とあわせて検討します。
