HAL9000
bdc2ccd6a3
This PR implements the Invariant data model and database schema for the v3.2.0 milestone. The Invariant feature enables the system to define, store, and manage invariant rules that can be evaluated against system state. - Alembic migration m3_001_invariants_table creates the invariants table with columns: id (UUID), description (text), created_at (timestamp), is_active (bool, default True), with index on is_active for efficiency - SQLAlchemy ORM InvariantModel in cleveragents.infrastructure.database.models.InvariantModel - M3 merge migration to resolve Alembic head conflict - BDD Behave scenarios (10 test cases) in features/invariant_model.feature - Robot Framework integration tests in robot/invariant_model.robot - Updated CHANGELOG.md and CONTRIBUTORS.md - Restored status-check CI aggregation job ISSUES CLOSED: #8524
60 lines
2.3 KiB
Gherkin
60 lines
2.3 KiB
Gherkin
Feature: Invariant data model and database schema
|
|
As a developer
|
|
I want an Invariant SQLAlchemy model with a corresponding database schema
|
|
So that invariant rules can be persisted and queried efficiently
|
|
|
|
Background:
|
|
Given a fresh in-memory invariant database
|
|
|
|
Scenario: Create an Invariant with all required fields
|
|
Given a new Invariant with description "All plans must have a goal"
|
|
When I persist the Invariant
|
|
Then I can retrieve the Invariant by its ID
|
|
And the persisted Invariant description should be "All plans must have a goal"
|
|
|
|
Scenario: is_active defaults to True
|
|
Given a new Invariant with description "Default active invariant"
|
|
When I persist the Invariant
|
|
Then I can retrieve the Invariant by its ID
|
|
And the persisted Invariant is_active should be True
|
|
|
|
Scenario: created_at is auto-populated on insert
|
|
Given a new Invariant with description "Timestamped invariant"
|
|
When I persist the Invariant
|
|
Then I can retrieve the Invariant by its ID
|
|
And the persisted Invariant created_at should not be empty
|
|
|
|
Scenario: id is a UUID string
|
|
Given a new Invariant with description "UUID invariant"
|
|
When I persist the Invariant
|
|
Then I can retrieve the Invariant by its ID
|
|
And the persisted Invariant id should be a valid UUID
|
|
|
|
Scenario: description is required and cannot be empty
|
|
Given a new Invariant with an empty description
|
|
When I try to persist the Invariant
|
|
Then a ValueError should be raised for empty description
|
|
|
|
Scenario: Query active invariants
|
|
Given 3 active Invariants and 2 inactive Invariants
|
|
When I query Invariants filtered by is_active True
|
|
Then I should get 3 Invariants
|
|
|
|
Scenario: Query inactive invariants
|
|
Given 3 active Invariants and 2 inactive Invariants
|
|
When I query Invariants filtered by is_active False
|
|
Then I should get 2 Invariants
|
|
|
|
Scenario: Deactivate an Invariant
|
|
Given a persisted active Invariant
|
|
When I set is_active to False on the Invariant
|
|
Then the Invariant is_active should be False
|
|
|
|
Scenario: Migration upgrade creates invariants table
|
|
Given a fresh in-memory invariant database
|
|
Then the invariants table should exist
|
|
|
|
Scenario: Migration creates index on is_active
|
|
Given a fresh in-memory invariant database
|
|
Then the invariants table should have an index on is_active
|