แยกการทดสอบด้วยฐานข้อมูลทดสอบ

Tests must never touch your real data. A test database keeps every run clean, so one test can never corrupt another or your production rows.

The easy choice is an in-memory SQLite database. It lives only in RAM and vanishes the moment the test process ends.

Set TESTING to True before tests run. It turns off error catching so exceptions surface clearly in your output.

Inside an app context, call db.create_all(). It builds every table from your models so each test run starts from an empty schema.

After the test, call db.drop_all() to remove every table. This guarantees the next run cannot inherit leftover rows.

Wrap setup and teardown in one fixture. The code before yield creates the schema; the code after it drops everything cleanly.

Many tests need a known row to read. Add a record in the fixture, then commit it so the test starts from a predictable state.

Tests should pass in any order. Isolation means each test sees the same starting data, so results never depend on what ran before.

An alternative to recreating tables is a rollback. Wrap each test in a transaction and undo it afterward for a fast, clean slate.

Store test settings in a dedicated TestConfig class. Your factory loads it only during tests, never in development or production.

Always double-check the URI points at a test database. Pointing tests at production data is the fastest way to lose real records.

You want tests that never harm real data. What database do you use?

You spin up a clean test database, seed known data, and tear it down after. Now your tests are fast, repeatable, and safe. 🗄️