Files
cleveragents-core/features/resource_registry_service_coverage.feature
T
freemo 77a0a95dc3
CI / lint (pull_request) Successful in 26s
CI / security (pull_request) Successful in 26s
CI / typecheck (pull_request) Successful in 1m2s
CI / quality (pull_request) Successful in 17s
CI / build (pull_request) Successful in 25s
CI / integration_tests (pull_request) Failing after 3m2s
CI / lint (push) Successful in 23s
CI / unit_tests (pull_request) Failing after 17m24s
CI / docker (pull_request) Has been skipped
CI / typecheck (push) Successful in 40s
CI / security (push) Successful in 37s
CI / quality (push) Successful in 25s
CI / build (push) Successful in 16s
CI / integration_tests (push) Failing after 7m16s
CI / unit_tests (push) Failing after 24m35s
CI / docker (push) Has been skipped
CI / coverage (pull_request) Failing after 37m0s
CI / coverage (push) Failing after 37m15s
Tests: Added coverage to get us to 97%
2026-02-17 21:00:05 -05:00

60 lines
3.4 KiB
Gherkin

Feature: Resource registry service coverage gaps
Cover exception-handling rollback paths and auto_discovery/equivalence
serialisation round-trips in ResourceRegistryService, _spec_to_db, and
_db_to_spec.
# Exception rollback paths
Scenario: bootstrap_builtin_types rolls back on unexpected exception
Given a resource registry service with a faulty session for bootstrap
When I call bootstrap_builtin_types and it fails
Then the faulty session should have been rolled back
And the original exception should propagate from bootstrap
Scenario: register_type rolls back on non-ValidationError exception
Given a resource registry service with a faulty session for register_type
And a temporary valid resource type YAML file exists
When I call register_type and a non-validation exception occurs
Then the register_type faulty session should have been rolled back
And the original non-validation exception should propagate from register_type
Scenario: register_resource rolls back on generic exception
Given a resource registry service with a faulty session for register_resource
When I call register_resource and a generic exception occurs
Then the register_resource faulty session should have been rolled back
And the original generic exception should propagate from register_resource
# ── _spec_to_db auto_discovery and equivalence ────────────────────
Scenario: _spec_to_db serialises auto_discovery to JSON
Given a ResourceTypeSpec with auto_discovery set
When I convert the spec to a database model via _spec_to_db
Then the database model auto_discover_json should contain the auto_discovery data
Scenario: _spec_to_db serialises equivalence to JSON
Given a ResourceTypeSpec with equivalence set
When I convert the equivalence spec to a database model via _spec_to_db
Then the database model equivalence_json should contain the equivalence data
# ── _db_to_spec auto_discovery and equivalence ────────────────────
Scenario: _db_to_spec parses auto_discover_json from a database row
Given an in-memory database with a resource type row containing auto_discover_json
When I convert the database row back to a spec via _db_to_spec
Then the resulting spec auto_discovery should match the original data
Scenario: _db_to_spec parses equivalence_json from a database row
Given an in-memory database with a resource type row containing equivalence_json
When I convert the equivalence database row back to a spec via _db_to_spec
Then the resulting spec equivalence should match the original equivalence data
# ── Round-trip through real DB ────────────────────────────────────
Scenario: auto_discovery and equivalence survive a full register-and-show round-trip
Given a real in-memory resource registry service is initialised
And a YAML config with auto_discovery and equivalence fields exists
When I register the type with auto_discovery and equivalence via the service
And I show the registered type with auto_discovery and equivalence
Then the shown type should have the correct auto_discovery
And the shown type should have the correct equivalence