Testing Strategies

Introduction

Testing in Seaography is centered around verifying the integration between SeaORM entities and the dynamic GraphQL schema generated by async-graphql. The strategy focuses on end-to-end execution of GraphQL queries and mutations against live database instances (SQLite, PostgreSQL, and MySQL) to ensure that filters, pagination, and relational mapping function correctly.

The primary objective is to validate that the BuilderContext configurations, such as depth limits, complexity limits, and lifecycle hooks, are respected during query execution. Tests typically involve setting up a schema builder with specific context, executing raw GraphQL strings, and asserting the resulting JSON data against expected outcomes.

Sources: examples/sqlite/tests/more_query_tests.rs, examples/postgres/tests/query_tests.rs, generator/src/templates/axum.rs:55-65

Core Testing Components

Schema Initialization for Tests

Tests begin by initializing a database connection and using the query_root::schema_builder to generate an executable async_graphql::dynamic::Schema. This allows tests to run without starting a full web server, using a test_writer for tracing logs.

The diagram shows the standard flow for preparing a testable GraphQL schema within the test suite.
Sources: examples/sqlite/tests/more_query_tests.rs:25-30, generator/src/templates/axum.rs:60-65

Assertion Logic

A common utility function assert_eq is used across test files. It executes a GraphQL query, converts the response data to JSON, and compares it against a provided JSON string or serde_json::Value.

Sources: examples/sqlite/tests/more_query_tests.rs:32-37, examples/postgres/tests/query_tests.rs:13-18

Integration Testing Scenarios

Filtering and Operator Validation

Tests extensively cover various filtering scenarios, including basic equality, null checks (is_null), and range operators (lt, gt). This ensures the translation from GraphQL input objects to SeaORM Condition objects is accurate.

This sequence illustrates how filter inputs are propagated through the system during a test case.
Sources: examples/sqlite/tests/more_query_tests.rs:40-100, examples/postgres/tests/query_tests.rs:45-70

Pagination Testing

Seaography supports multiple pagination strategies which are validated through specific test cases:

• Page-based: Validates paginationInfo (total pages, current page).
• Cursor-based: Validates pageInfo (startCursor, endCursor, hasNextPage) and opaque cursor decoding.
• Offset-based: Validates limit/offset logic.
• Default/Max Limits: Tests ensure that BuilderContext limits are enforced, returning errors when requested limits exceed maximums.

Sources: src/query/pagination.rs:16-100, examples/sqlite/tests/more_query_tests.rs:152-178

Lifecycle Hooks and Security

Testing strategies include verifying LifecycleHooksInterface implementations. Tests define a MyHooks struct to intercept entity resolution and apply automatic filters (e.g., multi-tenancy simulation by filtering by StoreId).

impl LifecycleHooksInterface for MyHooks {
    fn entity_filter(
        &self,
        _ctx: &ResolverContext,
        entity: &str,
        _action: OperationType,
    ) -> Option<Condition> {
        match entity {
            "Customer" | "Customers" => Some(Condition::all().add(customer::Column::StoreId.eq(2))),
            _ => None,
        }
    }
}

Sources: examples/sqlite/tests/entity_filter_tests.rs:20-35

Database-Specific Testing

Because the project supports multiple backends, the test suite includes specific implementations for:

1. SQLite: Uses local .db files (e.g., sakila.db).
2. PostgreSQL: Connects to a running instance (typically postgres://sea:sea@127.0.0.1/sakila).
3. Feature Flags: Tests use #[cfg(feature = "field-pluralize")] to verify naming convention changes (singular vs plural query fields).

Sources: examples/sqlite/tests/plural_query_tests.rs:7-11, examples/postgres/tests/query_tests.rs:6-11, examples/sqlite/tests/entity_filter_tests.rs:46-55

Summary

The testing strategy for Seaography relies on robust integration tests that simulate real-world GraphQL operations. By leveraging BuilderContext and schema_builder directly in tests, the project ensures that its dynamic schema generation remains consistent across different databases and configuration states, particularly regarding pagination limits, relational filters, and security hooks.