freemo
c9abb45adf
test(coverage): add Behave BDD scenarios for 9 under-covered modules
...
Added 246 new BDD scenarios across 9 feature files to improve unit test
coverage for modules that were either entirely untested or had significant
coverage gaps:
- lock_service_coverage.feature (27 scenarios): validation branches,
TTL boundaries, re-entrant acquisition, rollback on exceptions
- plan_apply_service_coverage.feature (54 scenarios): operation labels,
diff rendering (plain/rich/json), artifact building, validation gate,
changeset resolution and cleanup
- plan_executor_coverage.feature (51 scenarios): step parsing, execute
actor integration, strategize/execute guards, stub retry/recovery,
decision tree construction
- skill_cli_coverage_r3.feature (22 scenarios): tools refresh, list/show
JSON fallback, capability summary errors, remove confirmation
- changeset_repository_coverage.feature (39 scenarios): entry/tool repos
validation, database error wrapping, domain conversion, SQLite store
CRUD operations
- repositories_coverage.feature (20 scenarios): get_by_name/namespace
errors, list_available filters, delete with ActionInUseError, plan
update with invariants/processing_state/error_details
- sandbox_copy_on_write_coverage.feature (12 scenarios): create OSError
wrapping, get_path state transitions, commit edge cases, rollback
errors, cleanup with missing paths
- bridge_coverage.feature (8 scenarios): __del__ suppression, async task
cancellation, execute_graph message type handling, stream config,
state checkpointer
- plan_cli_coverage.feature (13 scenarios): legacy apply/list/cd paths,
use-action with estimation/invariant actors, lifecycle-apply guards,
status errors, error recovery display
All 246 scenarios (1105 steps) pass. Step definitions use unique prefixes
to prevent ambiguous step conflicts with existing tests.
ISSUES CLOSED : #467
2026-02-27 13:47:42 -05:00
freemo
55aee7cf22
fix(test): commit after each add_skill to prevent session GC rollback, and improved coverage.
...
The step_register_skills_table step called add_skill in a loop but only
committed once at the end. Because SkillRepository.create() obtains a
new session per call and only flushes (never commits), the intermediate
sessions could be garbage-collected before the final commit, rolling
back their transactions on the shared SQLite :memory: connection. Moving
_commit_pending inside the loop ensures each skill is durably committed
before the next session is created.
ISSUES CLOSED : #418
2026-02-24 12:19:04 -05:00
freemo
