【FastAPI】テストケース毎に独立したDBデータを使用する（GitHub Actions付き） - Qiita
ORMと連携した機能のテストを行う際、テストケース(= テスト関数)毎にクリーンなデータベースが欲しい（テストケース間の依存関係が生まれてほしくない）。 この点についていい感じの方法が実現できたためご紹介する。 参考（一部重複内容あり） FastAPIでテスト用のクリーンなDBを作成してpytestでAPIのUnittestを行う 本記事のソースコード：skokado/fastapi-tutorial 環境 Python: 3.8 fastapi==0.68.2 SQLAlchemy==1.4.25 SQLAlchemy-Utils==0.37.8 pytest==6.2.5 factory-boy==3.2.0 アプリケーション準備 ユーザ認証とブログ管理を行う簡単なアプリケーションを用意する。 ※アプリケーション本体のコードは割愛するためリポジトリを参照 ※ディレクトリ構成 . ├──
[pytest] monkeypatchを広いスコープで使う - Qiita
はじめに pytestで単体テストを書いているときに以下のようなエラーに遭遇したことはないでしょうか。 ScopeMismatch: You tried to access the 'function' scoped fixture 'monkeypatch' with a 'module' scoped request object, involved factories この記事では、このエラーについて解説し解決策を示します。 エラーの解説 エラーメッセージに書いてある通り、functionスコープのfixtureであるmonkeypatchをより広いmoduleスコープで使おうとしたことによって、スコープがあっていないよ！と言われています。 pytestではfixtureの中で別のfixtureを入力として受け取り、使用することができます。この時気をつけなくてはいけないのは、fixt
![[pytest] monkeypatchを広いスコープで使う - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/90e113e8e8560e90e097fcf4b112f2438f66e315/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Farticle-ogp-background-412672c5f0600ab9a64263b751f1bc81.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTk3MiZoPTM3OCZ0eHQ9JTVCcHl0ZXN0JTVEJTIwbW9ua2V5cGF0Y2glRTMlODIlOTIlRTUlQkElODMlRTMlODElODQlRTMlODIlQjklRTMlODIlQjMlRTMlODMlQkMlRTMlODMlOTclRTMlODElQTclRTQlQkQlQkYlRTMlODElODYmdHh0LWFsaWduPWxlZnQlMkN0b3AmdHh0LWNvbG9yPSUyMzFFMjEyMSZ0eHQtZm9udD1IaXJhZ2lubyUyMFNhbnMlMjBXNiZ0eHQtc2l6ZT01NiZzPTMyNWRjZDQzZGM0N2JjYTAyYTFlYTI4MDRhNzEwZThj%26mark-x%3D142%26mark-y%3D57%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZoPTc2Jnc9NzcwJnR4dD0lNDBfeXVfeXVfeXUmdHh0LWNvbG9yPSUyMzFFMjEyMSZ0eHQtZm9udD1IaXJhZ2lubyUyMFNhbnMlMjBXNiZ0eHQtc2l6ZT0zNiZ0eHQtYWxpZ249bGVmdCUyQ3RvcCZzPTQxOTdkOTdmODE4YmI0NWZiNzcyMDRiY2VjMjdmYjFl%26blend-x%3D142%26blend-y%3D486%26blend-mode%3Dnormal%26s%3Da94dc5cbe0a97c0a60487763a69d4ad5)
pytestのfixtureを引数付きで実行して戻り値を返却して後処理をする方法 - Qiita
pytestのfixtureを引数付きで実行と戻り値の返却をして後処理をする際に少しつまづいたので、備忘録として残しておく。 はじめに 以下のやり方は、分かっていたが、戻り値を返却した後、テスト後の処理を追加する方法がわからなかった 後処理を実行する方法 @pytest.fixture def setUp(): print('start') yield print('end')
ユニットテスト大事なのでちゃんと勉強した話 - Qiita
まえがき 私は、弊社の案件で運用しているAIシステムで、主にバッチ処理を定期的に動かしたり、リリースを管理したりと、アルゴリズム開発というよりは主にインフラ側の保守を担当しています。 納期が短かったため、開発当時は「本番環境でバッチが動けばオッケー牧場！」というマインドで運用していました。 事前テストも、あらかじめ本番環境に近い環境で動かして、正常に動くことを目視確認していました。 本当は、モジュールも１つずつテストしたいんですよね。 なんでテストが必要なの? でも、テストって、ぶっちゃけめんどくさいですよね、書くの。 コードの実装がすでに頭に浮かんでいて、さっさと実コードを書いてしまいたい場合が多いと思います。 「動いてんだからいいじゃん！」実際、私もそうでした。 しかし、ことデータシステムにおいては、次のようなケースがよくあることがわかりました。 タイムゾーン無しの時刻型で処理していた
PySide & Pytest での テスト駆動開発 スタートアップ - Qiita
はじめに PySide勉強会での、「PySide & Pytest で テスト駆動開発スタートアップ」の補足記事。 および、PySideとPytestでテスト駆動開発をするためのメモ。 開発環境 Windows 10 Python 3.7.7 Pytest サンプルファイル GitHub 初期整備 ディレクトリとファイルの準備 root |- sample | |- __init__.py | |- gui.py |- tests | |- __init__.py | |- conftest.py | |- unit | |- test_gui.py |- requirments.txt import sys from PySide2 import QtCore from PySide2 import QtWidgets class SampleDialog(QtWidgets.QDial
pytest mark を使用した実行するテストの絞り込み - Qiita
#!/usr/bin/env python import calc def test_add(): assert calc.add(6, 3) == 9 def test_sub(): assert calc.sub(6, 3) == 3 def test_adds(): assert calc.adds(6, 3, 1) == 10 $ pytest ========================== test session starts ========================== platform linux -- Python 3.8.3, pytest-6.2.5, py-1.11.0, pluggy-1.0.0 rootdir: /home/username/calc collected 3 items test_calc.py ...... [100%] ====
PythonのFastAPIをLambdaで動かそうと思ったらSQLModelも使ってみたくなったので調べてみた(テストまあまあ盛り) - Qiita
PythonのFastAPIをLambdaで動かそうと思ったらSQLModelも使ってみたくなったので調べてみた(テストまあまあ盛り)PythonunittestpytestSQLModel はじめに Pythonでデータ分析やスクレイピングや画像認識などをやっているのですが、Webアプリのバックエンドとして仕事で本格的に利用したいと思い、いろいろ調べてみると、AWSの LambdaでFastAPIを動かすとの話題が多く目に留まり、ふむふむ、と進めていくと、SQLModelも一緒に利用したいと思い、半日ほど試行錯誤してみたのでまとめてみたいと思います。 ソースはgithubに登録しております。 SQLModelの概要 SQLModelは、直感的で使いやすく、互換性が高く、堅牢になるように設計されており、Pythonの型アノテーションに基づき、PydanticとSQLAlchemyを利用して
[Python]コードサンプルが正しく動くことを担保し続けるためのdoctest入門 - Qiita
最近自作Pythonライブラリでがっつりdoctestを使い始めたので記事にまとめておきます。 doctestってなに？ dostring内に書くコードサンプルを実際にPythonで動かしてエラーにならないことや返却値が正しいかどうかをチェックすることができる機能です。 ※docstringについては必要に応じて以下の記事などをご確認ください。 ※Rustなどにも似たような機能がビルトインで入っています。 doctestを書くとなにが嬉しいの？ docstringにコードサンプルが載っているとユーザーがエディタ上などでさくっと使い方を確認できてユーザーフレンドリーです。 一方で書いただけだとそのコードサンプルはテストやLintでチェックされるわけではありませんので正常に動作しないケースが発生し得ます。書いたときは動いていても日々のアップデートでいつの間にか動かなくなってしまうこともあるかも
![[Python]コードサンプルが正しく動くことを担保し続けるためのdoctest入門 - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/8327c8f9ebe9dfcbe7f7dd1fabd718bbd8931005/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Farticle-ogp-background-412672c5f0600ab9a64263b751f1bc81.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTk3MiZoPTM3OCZ0eHQ9JTVCUHl0aG9uJTVEJUUzJTgyJUIzJUUzJTgzJUJDJUUzJTgzJTg5JUUzJTgyJUI1JUUzJTgzJUIzJUUzJTgzJTk3JUUzJTgzJUFCJUUzJTgxJThDJUU2JUFEJUEzJUUzJTgxJTk3JUUzJTgxJThGJUU1JThCJTk1JUUzJTgxJThGJUUzJTgxJTkzJUUzJTgxJUE4JUUzJTgyJTkyJUU2JThCJTg1JUU0JUJGJTlEJUUzJTgxJTk3JUU3JUI2JTlBJUUzJTgxJTkxJUUzJTgyJThCJUUzJTgxJTlGJUUzJTgyJTgxJUUzJTgxJUFFZG9jdGVzdCVFNSU4NSVBNSVFOSU5NiU4MCZ0eHQtYWxpZ249bGVmdCUyQ3RvcCZ0eHQtY29sb3I9JTIzMUUyMTIxJnR4dC1mb250PUhpcmFnaW5vJTIwU2FucyUyMFc2JnR4dC1zaXplPTU2JnM9N2E4M2IwNmYxNjg0ZGE4MDE5NzNiYTI2NWJjYmJiYjk%26mark-x%3D142%26mark-y%3D57%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZoPTc2Jnc9NzcwJnR4dD0lNDBzaW1vbnJpdGNoaWUmdHh0LWNvbG9yPSUyMzFFMjEyMSZ0eHQtZm9udD1IaXJhZ2lubyUyMFNhbnMlMjBXNiZ0eHQtc2l6ZT0zNiZ0eHQtYWxpZ249bGVmdCUyQ3RvcCZzPWE3MmIwZGNhMjJjN2FmZWNiMjUzZTBmYzg4N2M5NDZh%26blend-x%3D142%26blend-y%3D486%26blend-mode%3Dnormal%26s%3D3ae9391eba5136bba51ce87fdf174592)
pytest（主に pytes-mock）のモックについて、ややこしいと思ったこと - Qiita
はじめに pythonとユニットテストについて学び始めたのでメモを残す。 誤りや意見などあれば、是非お願いします。 今回は、osモジュールを例にモックするパターンを考えていこうと思う。 大きく2つに分けて、下記パターンを考える。 mocker.patch()でモジュールの対象メソッドをモックする mocker.patch.object()でモジュールの対象メソッドをモックする (オプション)monkeypatch.setattr()でモックする また、from ~ importを利用する場合の考慮点も書いてみる。 boto3 モジュールのモックについても余力があれば書きたい。 学習する中で思ったこと pythonのユニットテストは、そこそこ種類（名前が違うだけで動作はほぼ同じはず）があり混乱した。 このstackoverflowの内容に共感した。 テスト関係のモジュール pytest py
テストの並列実行に使うpytest-xdistの便利な使い方まとめ(主にUIテスト向け) - Qiita
pytest-xdistとは pytest-xdistはテストの並列実行・分散実行に使うpytestのプラグインです。 これをインストールし、実行時に並列ノード数をオプションとして渡すだけで、勝手にテストを振り分けて実行してくれます。 本記事ではpytest-xdistを実際に使ってみて分かった便利な使い方、オプションなどをメモとしてまとめます。 なお、私はpytestをユニットテストではなく、主にSeleniumやPlaywrightを使ったUIテスト用途に利用しているため、それに特化した内容になっていることをご承知おきください。 内容は随時更新します。 インストール pip install pytest-xdist テストの並列実行 pytest -n 4 test.py -nのあとにテストを並列実行するノード数(ワーカー数)を入力します。 数値の代わりにautoを指定すると利用可能な
pytestで曖昧だったこと（Mock,spec,wrap) - Qiita
はじめに 自作のclassをモックする際に、調べたことをメモる。 クラス自体をモックする mocker.patch(’モジュール名.Class名’, autospec=True) でモックする 返り値にmockオブジェクトが取得できる return_value, side_effect, assert_called系メソッドが利用できる autospecを利用することで、モック対象のClassの属性・操作を模倣できる。定義なしにアクセスすると例外発生させることができる。 mock = mocker.Mock(spec=モジュール名.Class名) で一回、mockを定義する そして、mocker.patch(’モジュール名.Class名’, mock) でモックする このときpatchからの返り値もモックオブジェクトが取得でき、第2引数で指定したmockと同一変数 mocker.patch
ざっくり分かるpytestのfixture - Qiita
pytestにおけるfixtureとは テストの事前処理、事後処理を記載できるpytestの機能です。 SetUp(事前処理), TearDown(事後処理)を1つの関数で書けます。 setup_class, setup_functionのように、スコープごとに違う関数を呼ぶ必要がありません。 fixtureからfixtureを呼び出すことができ、処理を階層的に記述できます。 SetUp, TearDownじゃダメなの？ ダメかと言われるとダメじゃありません。チーム内でスタイルが統一されている方が大事です。 機能面だけで言うと、pytestにおいてはfixtureを利用する方がリッチではあります。 ブラウザ操作自動化ツールであるPlaywright for Pythonはfixtureを利用しています。 上記を採用する場合、可読性と保守性の観点からfixtureに統一することを勧めます。
pytest fixtureでユニットテストの前処理をする - Qiita
Pytestによるテスト実行前に「環境設定をテスト用に差し替えたいなあ...」と思うことがありました。(接続先データベース等) pytestコマンドの実行前に手動で環境変数を書き換えることも可能ですが、煩わしいので自動化したいです。 そこで今回はpytest fixtureでテストの実行前に自動で環境変数を書き換えました。 pytest fixtureを使えばテストの実行前に特定の処理を自動で実行することができます。 環境 Python3.8.10 pytest flask ソースコード from http.client import BAD_REQUEST, INTERNAL_SERVER_ERROR, NOT_FOUND from dotenv import load_dotenv from flask import (Flask) from app.presentation.shar
Playwright for PythonでPytestコードが生成できるようになった - Qiita
サマリ Playwright for PythonのVer.1.22からPytestコードが生成(codegen)できるようになっています。 本記事ではPlaywrightのインストールからPytestコードの生成までを試します。 Codegen now supports generating Pytest Tests インストール > playwright codegen --help Usage: playwright codegen [options] [url] open page and generate code for user actions Options: -o, --output <file name> saves the generated script to a file --target <language> language to generate, one
Python用GraphQLライブラリStrawberryのログ出力 ~スタックトレースを出力させない方法~ - Qiita
FastAPIの公式ドキュメントには、GraphQLのライブラリが紹介されています。 そこでおすすめのGraphQLのライブラリとして紹介されているのが、Strawberryです。 今回はStarawberryのライブラリを使ってGraphQLのAPIを実装しているときに、ログ出力で苦労したことがあったので、何が問題なのかとその解決方法を書きます。 Strawberryについて 改めてStrawberryとはPython用のGraphQLライブラリです。Python用のGraphQLのライブラリはGrapheneが古くからあるライブラリでドキュメントを豊富です。対してStrawberryは比較的新しいライブラリです。 FastAPIのドキュメントには、Strawberryを使用することをお勧めしています。 FastAPIとの設計思想が似ているらしいです。 Strawberryはまだまだ開発
Fast API を使って、改めて RESTful API と GraphQL を学び直してみた - Qiita
API のバージョン管理 疎結合なシステムにはバージョン管理が必要です。バージョン管理により、クライアント側のシステムやプログラム更新などを考慮せずに、API を改修することができます パフォーマンスを意識する 単に API を実行すると、リソースの取得をはじめとしたコストがかかります。以下の点を意識すると、パフォーマンスを落とさずに作成することができます キャッシュの活用 データ圧縮 パラメータは最小限（簡潔なパラメータ設定） 非同期処理 データ分割 また、日々パフォーマンスを監視して、重い処理がないかを視ることも重要です GraphQL とは GraphQL は、API を開発するためのクエリ言語、ランタイムの一種です。Meta（旧 Facebook）社によって 2015 年頃に公開されました。 GraphQL は、REST の課題を解決するために生まれたもので、以下の要素によって構成
DjangoでSwaggerUIを使おう！設定方法を徹底解説 - Qiita
INSTALLED_APPS = [ "rest_framework", # 先ほどインストールしたdrf_spectacularを記述 "drf_spectacular", ] DEFAULT_AUTO_FIELD = "django.db.models.BigAutoField" REST_FRAMEWORK = { 'DEFAULT_SCHEMA_CLASS': 'drf_spectacular.openapi.AutoSchema', } SPECTACULAR_SETTINGS = { 'TITLE': 'プロジェクト名', 'DESCRIPTION': '詳細', 'VERSION': '1.0.0', # api/schemaを表示しない 'SERVE_INCLUDE_SCHEMA': False, } from django.urls import path from dr
FastAPIで自動生成されるドキュメントを保存する方法 - Qiita
はじめに FastAPI は、WebAPI を構築するためのモダンなWebフレームワークです。 類似したフレームワークに、Django(Rest framework)やFlaskがありますが、大きな特徴として、コードからOpenAPIに準拠したAPIドキュメントを自動生成できることが挙げられます。/docsや/redoc、/openapi.jsonで見れるやつです。 ただ、自動生成されるドキュメントを保存する方法についてあまり日本語の情報が見つからなかったのでまとめておきます。 (フロントエンドとバックエンドで分かれて開発を行なっていて、APIの仕様だけ決めてドキュメントをGitHubPagesなどで共有、それを元にそれぞれ作業を進めたい時などに便利かと思います。) openapi()メソッドを利用してhtmlを生成する FastAPIにはopenapiスキーマを返すopenapi()メソ
DjangoでAPIドキュメントを自動生成しよう - Qiita
開発している家計簿アプリSUMUMAのAPIとAPIドキュメントを公開しました。 ドキュメントはSwaggerとRedocの2種類で公開しています。 Swagger SUMUMA API Redoc SUMUMA API APIとドキュメントの公開には、Django Rest Frameworkとdrf-yasgを使いました。 Django Rest Framework Django Rest Framework（以下DRFで表記）は、DjangoアプリでAPIを提供するためのパッケージです。DjangoでAPIを実装するときに、必ずと言っていいほど使われています。 DRFはOpenAPIという、RESTful APIを定義するためのフォーマットをサポートしています。OpenAPIを元にAPIドキュメントを生成することもできます。 DRFのドキュメントには、パッケージを使わずにAPIドキュ
OpenAPIを用いてSwitchbot Hubのデータを取得するAPIを実装する - Qiita
はじめに OpenAPIはAPI実装における標準化された手法の一つです。OpenAPIには以下のメリットがあります。 API仕様書のフォーマットの統一 サーバーへのリクエストテスト機能 ツールを用いたコードの雛形の生成 本記事では、Switchbotのスマート家電からデータを取得するAPIをOpenAPIを用いて実装し、取得したデータを表示する方法を紹介いたします。 最終的な構成図は以下のようになります。 使用した環境： リモート環境（Ubuntu 20.04） Docker version 24.0.5 openapitools/openapi-generator-cli Python 3.8.10： streamlit numpy matplotlib また、データ取得をするスマート家電として、自宅においてある Switchbot Hub 2 を用いました。 0. 事前準備 Switc
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
