CoreRasurae
9753b31c7e
CI / quality (push) Successful in 36s
CI / lint (push) Successful in 38s
CI / typecheck (push) Successful in 49s
CI / security (push) Successful in 51s
CI / integration_tests (push) Successful in 55s
CI / unit_tests (push) Successful in 3m35s
CI / build (push) Successful in 33s
CI / coverage (push) Successful in 3m36s
CI / status-check (push) Successful in 3s
Add 13 BDD scenarios covering previously uncovered code paths: - SAFE_BUILTINS validation (sandbox.py: 0% → 100%) - ConfigurationError re-raise path (config.py: 99.3% → 100%) - CLI hello/main functions (cli.py: 72.7% → 90.9%) - GraphState message truncation (state.py: 98.7% → 100%) - ProgressBarManager update/context rendering (progress.py: 0% → 87.7%) - MessageRouter regex/exact/contains routing (message_router.py: 0% → 59.4%) - RoutingAdapter parse_routing_command (routing_adapter.py) - DynamicRouterNode pattern-based routing (dynamic_router.py) - EnhancedTemplateRegistry unknown template type (enhanced_registry.py: 99.2%) - CompositeAgent null-graph error path (composite.py: 97.8% → 98.6%) Cover routing_adapter.py (17% → 100%): all GOTO/ROUTE patterns, create_routing_node, create_conditional_router, dynamic config conversion. Cover dynamic_router.py (21% → 87%): execute with empty/dict/string messages, extract_message with colon parsing, config creation, graph extension with edge generation. Cover message_router.py (59% → 78%): regex, exact, contains, prefix, suffix match types, invalid regex handling, non-string message, set_state. Exercise Node._prepare_conversation_history with invalid configs, _runtime error paths, _execute_message_router with rules, _execute_agent with current_message and metadata propagation, _execute_function with dynamic_router, and _execute_conditional with content_contains/content_not_contains/content_starts_with and custom condition types. Improves nodes.py from 71.3% to 72.5%. Exercise PureGraphConfig, PureLangGraph init with dict/config, RxPyLangGraphBridge registration/connection/lookup, ReactiveStreamRouter operator creation and condition functions, ReactiveConfigParser config/route/graph parsing, ToolAgent tool execution with JSON, space-separated, single, file_read, progress_bar invocations, and ReactiveCleverAgentsApp init/dispose/visualization.
126 lines
6.2 KiB
Gherkin
126 lines
6.2 KiB
Gherkin
Feature: Deferred Template Rendering and Application
|
|
As a developer
|
|
I want deferred templates to render with context, process template definitions from YAML sections, and apply to configurations
|
|
So that templates containing Jinja2 syntax are safely deferred until rendering context is available
|
|
|
|
Background:
|
|
Given I have a clean test environment for deferred templates
|
|
|
|
Scenario: DeferredTemplate initialization and basic usage
|
|
Given I have a simple template string with Jinja2 syntax
|
|
When I create a DeferredTemplate instance
|
|
Then the template should be stored correctly
|
|
And the YAMLTemplateProcessor should be initialized
|
|
|
|
Scenario: DeferredTemplate render method with context
|
|
Given I have a template string with template variables
|
|
And I have a template context with variable values
|
|
When I render the deferred template with context
|
|
Then the template should be processed using YAMLTemplateProcessor
|
|
And the result should contain the rendered content
|
|
|
|
Scenario: DeferredTemplate render method with complex template
|
|
Given I have a complex template string with multiple variables
|
|
And I have a comprehensive template context
|
|
When I render the deferred template with context
|
|
Then the template should be fully processed
|
|
And all variables should be substituted correctly
|
|
|
|
Scenario: DeferredTemplate from_yaml_section - missing key
|
|
Given I have a YAML dictionary without the target key
|
|
When I call from_yaml_section with the missing key
|
|
Then it should return None
|
|
|
|
Scenario: DeferredTemplate from_yaml_section - no template syntax
|
|
Given I have a YAML dictionary with a section without template syntax
|
|
When I call from_yaml_section with that key
|
|
Then it should return None
|
|
|
|
Scenario: DeferredTemplate from_yaml_section - with Jinja2 curly braces
|
|
Given I have a YAML dictionary with a section containing Jinja2 curly braces
|
|
When I call from_yaml_section with that key
|
|
Then it should return a DeferredTemplate instance
|
|
And the template string should contain the YAML section
|
|
|
|
Scenario: DeferredTemplate from_yaml_section - with Jinja2 control structures
|
|
Given I have a YAML dictionary with a section containing Jinja2 control structures
|
|
When I call from_yaml_section with that key
|
|
Then it should return a DeferredTemplate instance
|
|
And the template string should contain the control structures
|
|
|
|
Scenario: process_template_definition - no template sections
|
|
Given I have a template definition without template sections
|
|
When I call process_template_definition
|
|
Then it should return the original definition unchanged
|
|
|
|
Scenario: process_template_definition - with template sections without syntax
|
|
Given I have a template definition with sections but no template syntax
|
|
When I call process_template_definition
|
|
Then it should return the original definition unchanged
|
|
|
|
Scenario: process_template_definition - with components containing templates
|
|
Given I have a template definition with components containing template syntax
|
|
When I call process_template_definition
|
|
Then it should create a deferred template for components
|
|
And the original components should be replaced with a placeholder
|
|
And the deferred template should be stored with the correct key
|
|
|
|
Scenario: process_template_definition - with nodes containing templates
|
|
Given I have a template definition with nodes containing template syntax
|
|
When I call process_template_definition
|
|
Then it should create a deferred template for nodes
|
|
And the original nodes should be replaced with a placeholder
|
|
|
|
Scenario: process_template_definition - with edges containing templates
|
|
Given I have a template definition with edges containing template syntax
|
|
When I call process_template_definition
|
|
Then it should create a deferred template for edges
|
|
And the original edges should be replaced with a placeholder
|
|
|
|
Scenario: process_template_definition - with operators containing templates
|
|
Given I have a template definition with operators containing template syntax
|
|
When I call process_template_definition
|
|
Then it should create a deferred template for operators
|
|
And the original operators should be replaced with a placeholder
|
|
|
|
Scenario: process_template_definition - with routing containing templates
|
|
Given I have a template definition with routing containing template syntax
|
|
When I call process_template_definition
|
|
Then it should create a deferred template for routing
|
|
And the original routing should be replaced with a placeholder
|
|
|
|
Scenario: process_template_definition - with multiple sections containing templates
|
|
Given I have a template definition with multiple sections containing template syntax
|
|
When I call process_template_definition
|
|
Then it should create deferred templates for all applicable sections
|
|
And all original sections should be replaced with placeholders
|
|
|
|
Scenario: apply_deferred_templates - no deferred templates
|
|
Given I have a configuration without deferred templates
|
|
And I have a generic template context
|
|
When I call apply_deferred_templates
|
|
Then it should return the original configuration unchanged
|
|
|
|
Scenario: apply_deferred_templates - with deferred templates
|
|
Given I have a configuration with deferred template markers
|
|
And I have DeferredTemplate instances in the configuration
|
|
And I have a generic template context
|
|
When I call apply_deferred_templates
|
|
Then the deferred templates should be rendered
|
|
And the deferred markers should be removed
|
|
And the rendered content should replace the placeholders
|
|
|
|
Scenario: apply_deferred_templates - with nested rendered content
|
|
Given I have a configuration with deferred templates that render to nested dictionaries
|
|
And I have a generic template context
|
|
When I call apply_deferred_templates
|
|
Then the nested content should be extracted correctly
|
|
And the actual section should be populated with the nested content
|
|
|
|
Scenario: apply_deferred_templates - with direct rendered content
|
|
Given I have a configuration with deferred templates that render to direct content
|
|
And I have a generic template context
|
|
When I call apply_deferred_templates
|
|
Then the direct content should be used as-is
|
|
And the configuration should be updated correctly
|