Files
cleveragents-core/features/lsp_config_fields.feature
T
hamza.khyari c97ec273a9
CI / build (pull_request) Successful in 21s
CI / helm (pull_request) Successful in 23s
CI / lint (pull_request) Successful in 26s
CI / quality (pull_request) Successful in 56s
CI / typecheck (pull_request) Successful in 1m2s
CI / security (pull_request) Successful in 1m7s
CI / integration_tests (pull_request) Successful in 5m51s
CI / unit_tests (pull_request) Successful in 7m29s
CI / docker (pull_request) Successful in 2m13s
CI / coverage (pull_request) Successful in 8m50s
CI / benchmark-publish (pull_request) Has been skipped
CI / e2e_tests (pull_request) Successful in 15m34s
CI / status-check (pull_request) Successful in 2s
CI / benchmark-regression (pull_request) Successful in 59m14s
feat(lsp): add missing LspServerConfig model fields
Add specification-required fields to LspServerConfig:

- description: str (max_length=1000, default='')
- transport: LspTransport enum (stdio/tcp/pipe, default=stdio)
- initialization: dict[str, Any] (LSP initializationOptions, default={})
- workspace_settings: dict[str, Any] (workspace/didChangeConfiguration, default={})

All fields have defaults for backward compatibility with existing
configs. LspTransport enum exported from lsp package.

Tests: 17 Behave scenarios, 5 Robot integration tests.
Existing LSP tests: 250/250 pass unchanged.

ISSUES CLOSED: #835
2026-03-30 11:51:27 +00:00

114 lines
5.6 KiB
Gherkin

Feature: LSP Server Config Fields
As a developer
I need LspServerConfig to support description, transport, initialization, and workspace_settings
So that I can fully configure LSP servers per the specification
# LspTransport enum
Scenario: LspTransport enum has stdio and tcp values
Given the LspTransport enum is defined
Then the LspTransport enum should have "stdio" value
And the LspTransport enum should have "tcp" value
Scenario: LspTransport default is stdio
Given I create a minimal LspServerConfig
Then the config transport should be "stdio"
# ── description field ─────────────────────────────────────────────
Scenario: LspServerConfig accepts description
Given I create a config with description "Pyright for Python type checking"
Then the config description should be "Pyright for Python type checking"
Scenario: LspServerConfig description defaults to empty string
Given I create a minimal LspServerConfig
Then the config description should be empty
Scenario: LspServerConfig description at exactly 1000 characters is valid
Given I create a config with a description of exactly 1000 characters
Then the config description should have length 1000
Scenario: LspServerConfig description at 1001 characters is rejected
When I try to create a config with a description of 1001 characters
Then a ValidationError should be raised for config
Scenario: LspServerConfig strips whitespace from description
Given I create a config with description " padded "
Then the config description should be "padded"
# ── transport field ───────────────────────────────────────────────
Scenario: LspServerConfig accepts tcp transport
Given I create a config with transport "tcp"
Then the config transport should be "tcp"
Scenario: LspServerConfig rejects invalid transport value
When I try to create a config with transport "websocket"
Then a ValidationError should be raised for config
Scenario: LspServerConfig rejects pipe transport (not in spec)
When I try to create a config with transport "pipe"
Then a ValidationError should be raised for config
# ── initialization field ──────────────────────────────────────────
Scenario: LspServerConfig accepts initialization options
Given I create a config with initialization {"python": {"pythonPath": "/usr/bin/python3"}}
Then the config initialization should have key "python"
And the config initialization "python" value should equal {"pythonPath": "/usr/bin/python3"}
Scenario: LspServerConfig initialization defaults to empty dict
Given I create a minimal LspServerConfig
Then the config initialization should be empty
Scenario: LspServerConfig rejects non-dict initialization
When I try to create a config with initialization as a string
Then a ValidationError should be raised for config
# ── workspace_settings field ──────────────────────────────────────
Scenario: LspServerConfig accepts workspace settings
Given I create a config with workspace_settings {"editor.formatOnSave": true}
Then the config workspace_settings should have key "editor.formatOnSave"
Scenario: LspServerConfig workspace_settings defaults to empty dict
Given I create a minimal LspServerConfig
Then the config workspace_settings should be empty
Scenario: LspServerConfig rejects non-dict workspace_settings
When I try to create a config with workspace_settings as a string
Then a ValidationError should be raised for config
# ── Serialization round-trip ──────────────────────────────────────
Scenario: LspServerConfig with all new fields serializes and deserializes
Given I create a config with all new fields populated
When I serialize the config to dict and back
Then the deserialized config should match the original exactly
Scenario: LspServerConfig to_dict includes new fields
Given I create a config with all new fields populated
When I call to_dict on the config
Then the config dict should include "description"
And the config dict should include "transport"
And the config dict should include "initialization"
And the config dict should include "workspace_settings"
# ── Backward compatibility ────────────────────────────────────────
Scenario: Existing configs without new fields still work
Given I create a LspServerConfig with only name, command, and languages
Then the config should have default description
And the config should have default transport
And the config should have default initialization
And the config should have default workspace_settings
# ── Registry accepts new fields ───────────────────────────────────
Scenario: LspRegistry accepts config with new fields
Given I have a clean LspRegistry
And I create a config with all new fields populated
When I register the config in the registry
Then the registry should contain the config
And retrieving the config should preserve all new fields