Testing Strategy

Relevant source files

The following files were used as context for generating this wiki page:

• examples/axum_example/service/tests/crud_tests.rs
• src/tasks/seed.rs
• Cargo.toml
• config/test.yaml
• examples/axum_example/README.md

The testing strategy for the SeaORM Pro project focuses on validating core CRUD (Create, Read, Update, Delete) operations, ensuring data integrity through seeding tasks, and maintaining infrastructure stability via environment-specific configurations. The strategy spans unit-level service tests, data initialization validation, and integration-ready configurations.

Sources: examples/axum_example/service/tests/crud_tests.rs, src/tasks/seed.rs, config/test.yaml

Service Layer Testing

The project employs automated tests to verify the business logic contained within the service layer. These tests utilize an in-memory SQLite database to ensure a clean, isolated environment for every test run, minimizing side effects and external dependencies.

CRUD Validation

Service tests specifically target the Mutation and Query cores. The test suite performs the following sequence of operations:

1. Schema Initialization: Dynamically creates tables from entities using SeaORM's Schema tool.
2. Creation: Validates that entities (e.g., post) are correctly persisted and return expected ActiveModel states with auto-incremented IDs.
3. Retrieval: Confirms that records can be fetched by ID and that the data matches the input.
4. Updates: Ensures that existing records can be modified and that changes are reflected in the database.
5. Deletion: Verifies both individual record deletion and bulk deletion, checking the number of rows affected.

Sources: examples/axum_example/service/tests/crud_tests.rs:1-100

In-Memory Database Flow

The following diagram illustrates the lifecycle of a typical service test using the in-memory backend.

The flow ensures that every test starts with a fresh schema and validates the round-trip of data from the service to the database and back.
Sources: examples/axum_example/service/tests/crud_tests.rs:6-15

Data Seeding and Environment Setup

A critical part of the testing and development strategy involves the SeedData task. This system allows for the rapid population of the database with known datasets, which is essential for consistent manual testing and demo environments.

Seed Data Task

The SeedData task handles different character encodings (UTF-16LE, WINDOWS-1252) and delimiters (tabs, tildes) to import data from .tsv files. It supports a refresh:true flag which triggers a full database reset via db::reset::<Migrator> before seeding.

Sources: src/tasks/seed.rs:32-55

Feature	Description	File Reference
refresh	Boolean flag to reset the database structure before seeding.	seed.rs:35
seed_table	Generic function to deserialize CSV/TSV into SeaORM ActiveModels and batch insert.	seed.rs:88
Batch Insert	Models are inserted in chunks of 100 to optimize performance.	seed.rs:118

Seeding Execution Sequence

The sequence below shows how the SeedData task processes various tables to build a complex dataset like AdventureWorks.

Infrastructure and Configuration

Testing is supported by specific configurations defined in test.yaml. This ensures that when the application runs in a test context, it uses optimized settings for stability and speed.

Test Environment Settings

The test configuration overrides standard behaviors to prevent data loss in production while enabling helpful debugging features during development.

• Logging: Debug level is enabled with pretty_backtrace to facilitate troubleshooting.
• Database Pool: Configured with a minimum of 5 and maximum of 50 connections, including a 30,000ms timeout.
• Safety Guards: dangerously_truncate and dangerously_recreate are explicitly set to false by default to prevent accidental data destruction, although auto_migrate is enabled to keep the schema current.

Sources: config/test.yaml:12-20, config/test.yaml:90-110

Dependency Management

The project distinguishes between standard and development dependencies to keep the production binary lean.

[dev-dependencies]
loco-rs = { version = "0.16", features = ["testing"] }
serial_test = { version = "3.1" }

Sources: Cargo.toml:42-44

Execution Commands

Tests and testing-related tasks are executed via standard cargo commands.

Command	Purpose
cargo test	Runs all unit and service-level tests.
cargo run task seed_data	Seeds the database with default data.
cargo run task seed_data refresh:true	Wipes the database and re-seeds.

Sources: examples/axum_example/README.md:16-20, src/tasks/seed.rs:13-17

The testing strategy ensures that both the code (via service tests) and the data (via seeding tasks) remain consistent throughout the development lifecycle. By utilizing in-memory databases and batch-inserted seed data, the project maintains a high degree of technical accuracy and reliability.