mirror of
https://github.com/fastapi/sqlmodel.git
synced 2025-08-17 20:01:41 +08:00
3d1766866f
This commit applies minor cleanups to the previously consolidated test files. The primary goal of this session was to address your feedback regarding the removal of unnecessary comments and ensuring the correct use of `from types import ModuleType`.
**Summary of Actions during this cleanup session:**
1. **Plan Re-evaluation:** After the initial consolidation work, I created a new plan to systematically review all changed files in batches.
2. **Batch Processing:** I went through the following batches of consolidated test files:
* Batch 1: `tests/test_advanced` and `tests/test_tutorial/test_code_structure`
* Batch 2: `tests/test_tutorial/test_connect`
* Batch 3: `tests/test_tutorial/test_create_db_and_table`
* Batch 4: `tests/test_tutorial/test_fastapi/test_app_testing` and `.../test_delete`
* Batch 5: `.../test_limit_and_offset` and `.../test_multiple_models`
* Batch 6: `.../test_read_one` and `.../test_relationships`
* Batch 7: `.../test_response_model` and `.../test_session_with_dependency`
* Batch 8 (partially): `.../test_teams/test_tutorial001.py` was processed. `.../test_simple_hero_api/test_tutorial001.py` was identified as missed before this submission.
3. **Cleanup Operations:** For each file in the processed batches:
* I checked for and removed superfluous comments (e.g., commented-out code that was no longer relevant, self-explanatory comments). Many files were already quite clean.
* I ensured `from types import ModuleType` was added if `ModuleType` was used as a type hint for a function parameter (typically the `module` fixture).
* I corrected type hints from `type` to `types.ModuleType` where applicable.
4. **Testing Limitations:** Throughout this cleanup session, I encountered an error indicating "The command affected too many files in the repo". This prevented me from verifying that the cleanups did not introduce regressions. The changes are based on visual inspection and targeted modifications.
**Unfinished Work:**
* The cleanup for `tests/test_tutorial/test_fastapi/test_simple_hero_api/test_tutorial001.py` was missed in Batch 8.
* Batches 9 through 19 of the cleanup plan, covering the remaining FastAPI subdirectories, and the general `test_insert`, `test_limit_and_offset`, `test_many_to_many`, `test_one`, `test_relationship_attributes`, and `test_where` directories, were not started.
This submission includes the cleanups made up to the partial completion of Batch 8. Further cleanup and full verification are still pending.
93 lines
3.9 KiB
Python
93 lines
3.9 KiB
Python
import importlib
|
|
import sys
|
|
import types
|
|
from typing import Any
|
|
|
|
import pytest
|
|
from sqlmodel import create_engine, SQLModel, Session, select
|
|
|
|
from ...conftest import needs_py310
|
|
|
|
|
|
@pytest.fixture(
|
|
name="module",
|
|
params=[
|
|
"tutorial003",
|
|
pytest.param("tutorial003_py310", marks=needs_py310),
|
|
],
|
|
)
|
|
def get_module(request: pytest.FixtureRequest, clear_sqlmodel: Any):
|
|
module_name = request.param
|
|
full_module_name = f"docs_src.tutorial.insert.{module_name}"
|
|
|
|
if full_module_name in sys.modules:
|
|
mod = importlib.reload(sys.modules[full_module_name])
|
|
else:
|
|
mod = importlib.import_module(full_module_name)
|
|
|
|
mod.sqlite_url = "sqlite://"
|
|
mod.engine = create_engine(mod.sqlite_url)
|
|
|
|
# Create tables. Tutorial003.py in insert focuses on refresh, so tables and initial data are key.
|
|
# It's likely main() handles this. If not, direct creation is a fallback.
|
|
if hasattr(mod, "create_db_and_tables"): # Some tutorials use this helper
|
|
mod.create_db_and_tables()
|
|
elif hasattr(mod, "Hero") and hasattr(mod.Hero, "metadata"): # Check for Hero model metadata
|
|
mod.Hero.metadata.create_all(mod.engine)
|
|
elif hasattr(mod, "SQLModel") and hasattr(mod.SQLModel, "metadata"): # Generic fallback
|
|
mod.SQLModel.metadata.create_all(mod.engine)
|
|
|
|
return mod
|
|
|
|
|
|
def test_tutorial(module: types.ModuleType, clear_sqlmodel: Any):
|
|
# The main() function in tutorial003.py (insert section) is expected to perform
|
|
# the operations that this test will verify (e.g., creating and refreshing objects).
|
|
module.main()
|
|
|
|
with Session(module.engine) as session:
|
|
heroes = session.exec(select(module.Hero)).all()
|
|
|
|
heroes_by_name = {hero.name: hero for hero in heroes}
|
|
# The asserted data matches tutorial001, which is how the original test was.
|
|
# This implies tutorial003.py might be demonstrating a concept (like refresh)
|
|
# using the same initial dataset as tutorial001 or that the test is a copy.
|
|
# We preserve the original test's assertions.
|
|
deadpond = heroes_by_name["Deadpond"]
|
|
spider_boy = heroes_by_name["Spider-Boy"]
|
|
rusty_man = heroes_by_name["Rusty-Man"]
|
|
|
|
assert deadpond.name == "Deadpond"
|
|
assert deadpond.age is None
|
|
assert deadpond.id is not None
|
|
assert deadpond.secret_name == "Dive Wilson"
|
|
|
|
assert spider_boy.name == "Spider-Boy"
|
|
assert spider_boy.age is None
|
|
assert spider_boy.id is not None
|
|
assert spider_boy.secret_name == "Pedro Parqueador"
|
|
|
|
assert rusty_man.name == "Rusty-Man"
|
|
assert rusty_man.age == 48
|
|
assert rusty_man.id is not None
|
|
assert rusty_man.secret_name == "Tommy Sharp"
|
|
|
|
# Tutorial003 specific checks, if any, would go here.
|
|
# For example, if it's about checking `refresh()` behavior,
|
|
# the `main()` in the tutorial module should have demonstrated that,
|
|
# and the state of the objects above should reflect the outcome of `main()`.
|
|
# The current assertions are based on the original test files.
|
|
# If tutorial003.py's main() modifies these heroes in a way that `refresh` would show,
|
|
# these assertions should capture that final state.
|
|
|
|
# Example: if Rusty-Man's age was updated in DB by another process and refreshed in main()
|
|
# then rusty_man.age here would be the refreshed age.
|
|
# The test as it stands checks the state *after* module.main() has run.
|
|
# In tutorial003.py, `main` creates heroes, adds one, then SELECTs and REFRESHES that one.
|
|
# The test here is more general, selecting all and checking.
|
|
# The key is that the data from `main` is what's in the DB.
|
|
# The test correctly reflects the state after the `create_heroes` part of main.
|
|
# The refresh concept in the tutorial is demonstrated by printing, not by changing state in a way this test would catch differently
|
|
# from tutorial001 unless the `main` function's print statements were being captured and asserted (which they are not here).
|
|
# The database state assertions are sufficient as per original tests.
|