78 lines
3.2 KiB
Gherkin
78 lines
3.2 KiB
Gherkin
Feature: Database Integration with Unit of Work and Repositories
|
|
As a developer
|
|
I want to ensure database operations work correctly
|
|
So that data is persisted reliably
|
|
|
|
Background:
|
|
Given I have a clean test database
|
|
And I have initialized the Unit of Work
|
|
|
|
Scenario: Create and retrieve a project using repository
|
|
When I create a project with name "test-project"
|
|
Then the project should be saved in the database
|
|
And I can retrieve the project using Unit of Work
|
|
And the project should have the correct properties
|
|
|
|
Scenario: Unit of Work commits all changes together
|
|
When I start a Unit of Work transaction
|
|
And I create a project "test-project" in the transaction
|
|
And I create a plan "test-plan" in the transaction
|
|
And I commit the transaction
|
|
Then both the project and plan should exist in the database
|
|
|
|
Scenario: Unit of Work rollback on error
|
|
When I start a Unit of Work transaction
|
|
And I create a project "test-project" in the transaction
|
|
And an error occurs during the transaction
|
|
Then the transaction should rollback
|
|
And no data should be saved to the database
|
|
|
|
Scenario: Repository pattern for plans
|
|
Given I have a project "test-project" in the database
|
|
When I create a plan "feature-1" for the project
|
|
And I create another plan "feature-2" for the project
|
|
Then I should be able to list all plans for the project
|
|
And I should be able to set "feature-2" as the current plan
|
|
And the current plan should be "feature-2"
|
|
|
|
Scenario: Context repository operations
|
|
Given I have a project with a current plan
|
|
When I add a file "test.py" to the context
|
|
And I add another file "main.py" to the context
|
|
Then I should be able to list all context files
|
|
And I should be able to remove "test.py" from context
|
|
And only "main.py" should remain in context
|
|
|
|
Scenario: Change repository tracks modifications
|
|
Given I have a project with a built plan
|
|
When I add a change to create "new_file.py"
|
|
And I add a change to modify "existing.py"
|
|
And I mark the first change as applied
|
|
Then the applied change should have an applied timestamp
|
|
And the second change should still be pending
|
|
|
|
Scenario: Service uses Unit of Work for transactions
|
|
When I use ProjectService to initialize a project
|
|
Then the service should use Unit of Work
|
|
And the database infrastructure should be initialized
|
|
And the project should be persisted correctly
|
|
|
|
Scenario: PlanService uses repositories
|
|
Given I have an initialized project for database testing
|
|
When I use PlanService to create a plan
|
|
Then the plan should be saved via repository
|
|
And the plan should be set as current
|
|
And I should be able to retrieve it
|
|
|
|
Scenario: ContextService uses repositories
|
|
Given I have a project with a plan
|
|
When I use ContextService to add files
|
|
Then the context should be saved via repository
|
|
And the files should be associated with the plan
|
|
And I should be able to query the context
|
|
|
|
Scenario: Unit of Work auto-migrates database on first access
|
|
Given I have a unit of work without initialization for "sqlite:///:memory:"
|
|
When I open a transaction which should auto-run migrations
|
|
Then the migration runner should be invoked once with confirmation
|