Write developer documentation on writing tests
評価
この issue はまだ評価されていません。
説明
After some reading and testing, I found that I think I want to stick with the following strategy for now:
- Migration testing, which tests the python api responses against the php ones, when set up against the same pre-populated database. This is so we ensure correctness for migration, and have explicit documentation about the differences (in the unit tests, though they should also end up on the migration page)
- Integration testing for expected paths. Simple tests that test the full Python stack, including FastAPI client, dependency injection, and database interactions. For these tests the data will be added to the database on a per-test level. This makes it easy and fast to run tests by any developer- no management of test database state needed. From measurements I did find that creating the TestClient for FastAPI has considerable overhead (approx. 60ms per test). For this reason, we limit this to one test per kind of expected response. E.g., for get_flow: one with a returned flow, one without a result.
- Test database functions directly on a database which have items inserted on a per-test level. This is still surprisingly responsive, so there is no need to mock anything out.
- Test the broader input/output of the different API methods by calling the Python functions directly instead of through the TestClient. This is so we can test more different scenarios, while being fast. It also ensures that if tests fail at the API level (point 1) but not here, we know it is due to changes of FastAPI its configuration. Database calls at this level can be mocked, to better isolate the input/output processing of this function. I have some consideration of not mocking anything out here, to avoid the extra boilerplate. The database fixtures are pretty performant (~2ms).
This is not set in stone. Perhaps we should not even separate tests out this much, and only factoring out the FastAPI layer is enough. If someone with more experience happens to read this, feel free to leave your thoughts :)
- 主要言語
- Python
- スター
- 17
- フォーク
- 50
- PR マージ指標
- 30日以内にマージされた PR はありません
環境構築
- Dockerfile または Docker Compose ファイルあり
- プルリクエストのテンプレートあり
- コントリビューションガイドなし
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
openml/server-api のほかの issue
-
behavior
難易度 2/5 1〜3時間 初心者へのやさしさ 62/100
openml/server-api#337 · コメント 1 件 ·
-
Redesign POST /data/untag for v2再び着手できるかも @omosola が 39 日前に担当しましたが、オープン中のプルリクエストはありません。 オープンproposal
openml/server-api#375 · コメント 2 件 · 担当者 1 名 ·
-
Redesign POST /data/tag for v2再び着手できるかも @omosola が 39 日前に担当しましたが、オープン中のプルリクエストはありません。 オープン
openml/server-api#374 · コメント 2 件 · 担当者 1 名 ·
-
Redesign POST /data/qualities/unprocessed/{data_engine_id}/{order} for v2再び着手できるかも @omosola が 39 日前に担当しましたが、オープン中のプルリクエストはありません。 オープン
openml/server-api#373 · 担当者 1 名 ·
-
Redesign POST /data/qualities for v2再び着手できるかも @omosola が 39 日前に担当しましたが、オープン中のプルリクエストはありません。 オープン
openml/server-api#372 · 担当者 1 名 ·
openml/server-api の issue をすべて見る
似ている issue
-
Performance: deprecated DeviceEntry.config_entries access blocks the event loop for tens of secondsオープン
難易度 2/5 1〜3時間 初心者へのやさしさ 75/100
tuya/tuya_cloud_ha_bridge#14 ·
-
bug
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
semantica-agi/semantica#1968 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 62/100
メンテナーはふだん 1 日以内に返信
-
agent: ready area: submission priority: high type: docs
難易度 2/5 1〜3時間 初心者へのやさしさ 62/100
dkritarth/scopewatch#213 ·
メンテナーはふだん 1 日以内に返信
-
Broken link in RELEASE.md対応中かも @Jah-yee が今日担当しました。 オープン
難易度 1/5 1時間未満 初心者へのやさしさ 88/100
sphinx-contrib/httpdomain#143 ·
メンテナーはふだん 1 日以内に返信