159 lines
6.9 KiB
Gherkin
159 lines
6.9 KiB
Gherkin
Feature: Memory Service Coverage
|
|
As a developer
|
|
I want to exercise memory service behavior
|
|
So that uncovered logic gains test coverage
|
|
|
|
Scenario: Conversation adapter returns buffer text when configured for summaries
|
|
Given a conversation adapter configured to return text values
|
|
When I load memory variables from the adapter
|
|
Then the adapter provides a string buffer representation
|
|
|
|
Scenario: Conversation adapter handles nested context and async operations
|
|
Given a conversation adapter with prune tracking
|
|
When I save nested user and ai context through the adapter
|
|
And I invoke the adapter async operations
|
|
Then the adapter normalizes all values and prunes history three times
|
|
|
|
Scenario: Memory service prunes history to the configured window
|
|
Given a memory service limited to 3 messages
|
|
When I add five interactions via save context
|
|
And I ask for the two most recent messages
|
|
And I ask for more messages than available
|
|
Then the service keeps only the three latest messages
|
|
And the recent message requests respect their sizes
|
|
And the service summary honors a 20 character limit
|
|
And memory variables expose history and counts
|
|
|
|
Scenario: Memory service manages direct messages and adapters
|
|
Given a memory service with default settings
|
|
When I add direct message objects to the service
|
|
And I inspect the default conversation adapter
|
|
And I reset the max message limit to 1
|
|
And I save a new interaction to enforce pruning
|
|
And I clear the service memory
|
|
Then the service computed token counts and summaries before clearing
|
|
And the service history is empty after clearing
|
|
And a custom conversation adapter returns text values
|
|
|
|
Scenario: Memory service uses SQL chat history when available
|
|
Given a patched SQL chat history for memory service
|
|
When I create a memory service with a connection string
|
|
Then the SQL history constructor receives the session and connection
|
|
And stored messages flow through the patched SQL history
|
|
|
|
# ==================== EntityMemory Tests ====================
|
|
|
|
Scenario: Track a new entity
|
|
Given a memory service with entity tracking enabled
|
|
When I track a project entity named "my-project"
|
|
Then the entity should be stored successfully
|
|
And the entity should have type "project"
|
|
And the entity mention count should be 1
|
|
|
|
Scenario: Track entity with metadata
|
|
Given a memory service with entity tracking enabled
|
|
When I track a plan entity named "feature-plan" with metadata
|
|
Then the entity metadata should include the provided values
|
|
And the entity should be retrievable by name and type
|
|
|
|
Scenario: Update existing entity increments mention count
|
|
Given a memory service with entity tracking enabled
|
|
And I have tracked a file entity named "main.py"
|
|
When I track the same entity again
|
|
Then the entity mention count should be 2
|
|
And the entity last_seen should be updated
|
|
|
|
Scenario: Get entities by type
|
|
Given a memory service with multiple entities tracked
|
|
When I get all entities of type "project"
|
|
Then I should receive only project entities
|
|
And I should not receive entities of other types
|
|
|
|
Scenario: Get all entities
|
|
Given a memory service with multiple entities tracked
|
|
When I get all tracked entities
|
|
Then I should receive all entities regardless of type
|
|
|
|
Scenario: Get recent entities
|
|
Given a memory service with multiple entities tracked over time
|
|
When I get the 3 most recent entities
|
|
Then I should receive entities sorted by last access time
|
|
And I should receive at most 3 entities
|
|
|
|
Scenario: Search entities by name
|
|
Given a memory service with multiple entities tracked
|
|
When I search for entities with "main" in the name
|
|
Then I should receive entities whose names contain "main"
|
|
And the search should be case-insensitive
|
|
|
|
Scenario: Remove specific entity
|
|
Given a memory service with entity tracking enabled
|
|
And I have tracked a context entity named "src/utils.py"
|
|
When I remove the entity
|
|
Then the entity should no longer exist
|
|
And attempting to get the removed entity should return None
|
|
|
|
Scenario: Clear all entities
|
|
Given a memory service with multiple entities tracked
|
|
When I clear all entities
|
|
Then the entity store should be empty
|
|
And get_entities should return an empty list
|
|
|
|
Scenario: Clear entities by type
|
|
Given a memory service with multiple entities tracked
|
|
When I clear only project entities
|
|
Then project entities should be removed
|
|
And entities of other types should remain
|
|
|
|
Scenario: Get entity summary
|
|
Given a memory service with multiple entities tracked
|
|
When I get the entity summary
|
|
Then the summary should include total entity count
|
|
And the summary should include counts by type
|
|
And the summary should include recent entities
|
|
|
|
Scenario: Entity type can be specified as string
|
|
Given a memory service with entity tracking enabled
|
|
When I track an entity with type specified as string "custom"
|
|
Then the entity should be tracked with EntityType.CUSTOM
|
|
And the entity should be retrievable using either string or enum type
|
|
|
|
Scenario: Entity store is accessible directly
|
|
Given a memory service with entity tracking enabled
|
|
When I access the entity_store property
|
|
Then I should receive the underlying EntityStore instance
|
|
And I can track entities through it directly
|
|
|
|
# ==================== Coverage Enhancement Tests ====================
|
|
|
|
Scenario: Entity from_dict deserializes entity from dictionary
|
|
Given an entity dictionary with valid data
|
|
When I create an Entity from the dictionary using from_dict
|
|
Then the Entity should have the correct name and type
|
|
And the Entity should have the correct metadata
|
|
And the Entity should have the correct timestamps
|
|
And the Entity should have the correct mention count
|
|
|
|
Scenario: Updating existing entity also updates metadata
|
|
Given a memory service with entity tracking enabled
|
|
And I have tracked a project entity named "metadata-project" with initial metadata
|
|
When I track the same project entity again with additional metadata
|
|
Then the entity metadata should contain both initial and additional values
|
|
And the entity mention count should be 2
|
|
|
|
Scenario: Remove non-existent entity returns False
|
|
Given a memory service with entity tracking enabled
|
|
When I attempt to remove an entity that does not exist
|
|
Then the remove operation should return False
|
|
|
|
Scenario: EntityStore with connection string triggers persistence
|
|
Given an entity store with a mock connection string
|
|
When I track an entity to trigger dirty state
|
|
Then the persist callback should mark the store as not dirty
|
|
And subsequent reads should find the entity
|
|
|
|
Scenario: Get summary returns empty string for empty conversation
|
|
Given a memory service with no messages
|
|
When I request the conversation summary
|
|
Then the summary should be an empty string
|