Generate BDD (Behavior Driven Development) feature files from RFC Manager source code analysis. Use for creating Gherkin-format documentation of XConf communication, TR-181 parameter processing, mTLS certificate selection, AccountID handling, Maintenance Manager integration, and reboot trigger behavior. Produces gap analysis between feature files and L2 test implementations.
BDD Feature Generator for RFC Manager
Purpose
Automatically generate BDD feature files in Gherkin format by analyzing the RFC Manager (rfcMgr) source code. This skill creates comprehensive behavioral documentation that can serve as:
Functional documentation of XConf server communication, JSON response processing, and TR-181 parameter application
Test specifications for L2 functional tests (test/functional-tests/)
Requirements traceability linking RFC Manager source code to observable behavior
Gap analysis baseline for comparing L2 tests vs implemented functionality
Usage
Invoke this skill when:
Documenting existing RFC Manager behavior in BDD format
Creating test specifications for new XConf features or parameters
Feature files are placed in test/functional-tests/features/.
Naming convention for RFC Manager:
Feature files follow the pattern rfc_{behavior_area}.feature:
Source Functionality
Feature File
Description
XConf HTTP communication
rfc_xconf_communication.feature
XConf server request/response, HTTP status codes
XConf request parameters
rfc_xconf_request_params.feature
URL query parameters sent to XConf
XConf configSetHash/Time
rfc_xconf_configsetHash_time.feature
Configuration hash and timestamp tracking
XConf RFC data processing
rfc_data.feature
JSON response feature data extraction
TR-181 parameter SET/GET
rfc_setget_param.feature
Parameter application via tr181 CLI
TR-181 local SET/GET
rfc_tr181_setget_local_param.feature
Local store parameter roundtrip
WebPA communication
rfc_webpa.feature
WebPA SET/GET via mock parodus binary
Feature enable/disable
rfc_feature_enable.feature
Feature control (HTTP 200 vs 304 responses)
Device offline status
rfc_device_offline_status.feature
Internet connectivity check behavior
Initialization failure
rfc_initialization_failure.feature
Unresolved XConf host, missing DNS
Single instance run
rfc_single_instance_run.feature
Lock file enforcement
AccountID handling
rfc_valid_accountid.feature
Valid AccountID resolution and application
Unknown AccountID
rfc_unknown_accountid.feature
Unknown/invalid AccountID behavior
Factory reset
rfc_factory_reset.feature
Store clear and re-application
Reboot required
rfc_reboot_required.feature
Reboot event via Maintenance Manager
Reboot trigger
rfc_trigger_reboot.feature
Account transition reboot trigger
Dynamic cert selection
rfc_dynamic_cert_selector.feature
P12 mTLS dynamic certificate
Static cert fallback
rfc_static_cert_selector.feature
PEM static certificate fallback
RFC properties override
rfc_override_rfc_prop.feature
rfc.properties override behavior
Step 4: Generate Feature Files
Use this template for RFC Manager feature files:
####################################################################################
# If not stated otherwise in this file or this component's Licenses.txt file the
# following copyright and licenses apply:
#
# Copyright [YEAR] RDK Management
#
# Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at
#
# http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.
####################################################################################
# Source: rfcMgr/{SourceFile}.cpp
# Test: test/functional-tests/tests/{TestFile}.py
@order-{N}
Feature: {Feature Title}
Background:
Given the rfcMgr binary is available at "/usr/bin/rfcMgr"
And the mock XConf HTTPS server is running on port 50053
And the RFC properties file exists at "/etc/rfc.properties"
Scenario: {Descriptive scenario name}
Given {precondition}
When {action — typically running rfcMgr or setting a parameter}
Then {expected outcome — log message, parameter value, or file content}
Step 5: Map Source Handlers to Scenarios
For each functional area in the RFC Manager source code, generate scenarios that exercise the corresponding behavior. Use the test helper constants and interfaces available in the L2 test infrastructure.
XConf Communication (from rfc_xconf_handler.cpp, xconf_handler.cpp):
Scenario: Successful XConf request with HTTP 200
Given RFC_XCONF_URL is set to "https://mockxconf:50053/featureControl/getSettings"
When the rfcMgr binary is executed
Then the log should contain "HTTP Response code: 200"
And the tr181store.ini file should be updated with parameters from the XConf response
Scenario: XConf returns 304 Not Modified
Given the configSetHash matches the previous request
When the rfcMgr binary is executed
Then the log should contain "HTTP Response code: 304"
And the tr181store.ini should remain unchanged
Scenario: SET and GET TR-181 parameter via tr181 CLI
Given the TR-181 store file exists at "/opt/secure/RFC/tr181store.ini"
When I SET "Device.DeviceInfo.X_RDKCENTRAL-COM_RFC.Bootstrap.OsClass" to "default" via tr181
And I GET "Device.DeviceInfo.X_RDKCENTRAL-COM_RFC.Bootstrap.OsClass" via tr181
Then the response should contain "default"
WebPA Communication (from rfc_common.cpp — WDMP path):
Scenario: SET parameter via WebPA
When I send a WebPA SET payload via the mock parodus binary:
"""
{"command":"SET","parameters":[{"name":"{param}","dataType":{type},"value":"{value}"}]}
"""
Then the parodus mock should exit with code 0
And the parodus log should contain '"statusCode":200'
And the parodus log should contain '"message":"Success"'
AccountID Handling (from rfc_xconf_handler.cpp):
Scenario: Valid AccountID extracted from XConf response
Given the XConf response contains a valid AccountID
When the rfcMgr binary processes the response
Then the log should contain the AccountID value
And the TR-181 parameter for AccountID should be set
Scenario: Unknown AccountID triggers error handling
Given the XConf response contains AccountID "3064488088886635972"
When the rfcMgr binary processes the response
Then the log should indicate an unknown AccountID
Certificate Selection (from mtlsUtils.cpp):
Scenario: Dynamic P12 certificate selection
Given LIBRDKCERTSELECTOR is enabled
And a valid P12 certificate is available
When the rfcMgr binary initiates XConf communication
Then the log should contain the dynamic certificate path
Scenario: Static PEM certificate fallback
Given no dynamic certificate selector is available
And "/etc/ssl/certs/client.pem" exists
When the rfcMgr binary initiates XConf communication
Then the log should contain "/etc/ssl/certs/client.pem"
Scenario: Reboot required event sent to Maintenance Manager
Given ENABLE_MAINTENANCE is set to "true" in device.properties
And the XConf response requires a reboot
When the rfcMgr binary completes processing
Then an IARM event MAINT_REBOOT_REQUIRED should be sent
Scenario: RFC complete event sent to Maintenance Manager
Given ENABLE_MAINTENANCE is set to "true" in device.properties
When the rfcMgr binary completes successfully
Then an IARM event MAINT_RFC_COMPLETE should be sent
Step 6: Use Scenario Outlines for Parameterized Tests
When multiple test variations share the same flow but differ in data, use Scenario Outline with Examples:
Scenario Outline: XConf communication with different HTTP response codes
Given RFC_XCONF_URL is set to "<url>"
When the rfcMgr binary is executed
Then the log should contain "HTTP Response code: <code>"
Examples:
| url | code |
| https://mockxconf:50053/featureControl/getSettings | 200 |
| https://mockxconf:50053/featureControl304/getSettings | 304 |
| https://mockxconf:50053/featureControl404/getSettings | 404 |
Step 7: Create Feature-to-Test Mapping
Maintain a mapping between feature files and their corresponding test implementations:
Feature File
Test File
Test Runner
rfc_single_instance_run.feature
test_rfc_single_instance_run.py
run_l2.sh
rfc_device_offline_status.feature
test_rfc_device_offline_status.py
run_l2.sh
rfc_initialization_failure.feature
test_rfc_initialization_failure.py
run_l2.sh
rfc_xconf_communication.feature
test_rfc_xconf_communication.py
run_l2.sh
rfc_setget_param.feature
test_rfc_setget_param.py
run_l2.sh
rfc_tr181_setget_local_param.feature
test_rfc_tr181_setget_local_param.py
run_l2.sh
rfc_data.feature
test_rfc_xconf_rfc_data.py
run_l2.sh
rfc_xconf_request_params.feature
test_rfc_xconf_request_params.py
run_l2.sh
rfc_valid_accountid.feature
test_rfc_valid_accountid.py
run_l2.sh
rfc_factory_reset.feature
test_rfc_factory_reset.py
run_l2.sh
rfc_trigger_reboot.feature
test_rfc_trigger_reboot.py
run_l2.sh
rfc_feature_enable.feature
test_rfc_feature_enable.py
run_l2.sh
rfc_xconf_configsetHash_time.feature
test_rfc_xconf_configsethash_time.py
run_l2.sh
rfc_reboot_required.feature
test_rfc_xconf_reboot.py
run_l2.sh
rfc_override_rfc_prop.feature
test_rfc_override_rfc_prop.py
run_l2.sh
rfc_unknown_accountid.feature
test_rfc_unknown_accountid.py
run_l2_reboot_trigger.sh
rfc_webpa.feature
test_rfc_webpa.py
run_l2_reboot_trigger.sh
rfc_dynamic_cert_selector.feature
test_rfc_dynamic_static_cert_selector.py
commented out
rfc_static_cert_selector.feature
test_rfc_static_cert_selector.py
commented out
Scenario Patterns for RFC Manager
XConf Communication Pattern
Scenario: {Description of XConf interaction}
Given RFC_XCONF_URL is configured in "/etc/rfc.properties"
And the mock XConf server returns HTTP {status_code}
When the rfcMgr binary is executed
Then the log file "/opt/logs/rfcscript.txt" should contain "{expected_log_entry}"
TR-181 Parameter SET/GET Pattern (tr181 CLI)
Scenario: SET and GET {parameter}
When I SET "{Device.Namespace.Parameter}" to "{value}" via tr181 CLI
And I GET "{Device.Namespace.Parameter}" via tr181 CLI
Then the response should contain "{value}"
WebPA SET/GET Pattern (mock parodus)
Scenario: SET {parameter} via WebPA
When I send a WebPA SET payload via mock parodus:
"""
{"command":"SET","parameters":[{"name":"{param}","dataType":{type},"value":"{value}"}]}
"""
Then the parodus mock should exit with code 0
And the parodus log should contain '"statusCode":200'
And the parodus log should contain '"message":"Success"'
Scenario: GET {parameter} via WebPA
When I send a WebPA GET payload via mock parodus:
"""
{"command":"GET","names":["{param}"]}
"""
Then the parodus mock should exit with code 0
And the parodus log should contain '"statusCode":200'
And the parodus log should contain '"value":"{expected}"'
Device Connectivity Check Pattern
Scenario: Device offline — no route available
Given the route file "/tmp/route_available" does not exist
And the DNS file "/etc/resolv.dnsmasq" does not exist
When the rfcMgr binary is executed
Then the log should contain "OFFLINE" or connectivity failure message
And the rfcMgr should exit without making XConf request
Scenario: Device online — route and DNS available
Given the route file "/tmp/route_available" exists
And the DNS file "/etc/resolv.dnsmasq" contains valid nameserver entries
When the rfcMgr binary is executed
Then the log should indicate successful connectivity check
Single Instance Lock Pattern
Scenario: Only one rfcMgr instance runs at a time
Given the lock file "/tmp/.rfcServiceLock" does not exist
When the rfcMgr binary is executed
Then the lock file should be created
And a second rfcMgr instance should fail to acquire the lock
Factory Reset Pattern
Scenario: Factory reset clears RFC stores
Given the TR-181 store contains existing parameters
When a factory reset is triggered
And the rfcMgr binary is re-executed
Then the store files should be cleared
And parameters should be re-applied from the XConf response
AccountID Handling Pattern
Scenario: AccountID from XConf response
Given the XConf response contains AccountID "{account_id}"
When the rfcMgr binary processes the response
Then the log should contain "AccountID: {account_id}"
And the TR-181 AccountID parameter should be set to "{account_id}"
Reboot Trigger Pattern
Scenario: Account transition triggers reboot
Given the previous AccountID was "{old_id}"
And the new XConf response contains AccountID "{new_id}"
When the rfcMgr binary processes the response
Then a reboot trigger event should be generated
Certificate Selection Pattern
Scenario: Dynamic mTLS certificate (P12)
Given LIBRDKCERTSELECTOR is compiled in
When the rfcMgr initiates HTTPS to XConf
Then the log should show dynamic certificate selection via RdkCertSelector
Scenario: Static mTLS certificate (PEM fallback)
Given the static certificate exists at "/etc/ssl/certs/client.pem"
When the rfcMgr initiates HTTPS to XConf
Then the log should show static certificate path "/etc/ssl/certs/client.pem"
Maintenance Manager Event Pattern
Scenario: RFC {status} event to Maintenance Manager
Given ENABLE_MAINTENANCE is "true" in "/etc/device.properties"
When the rfcMgr binary completes with {status}
Then an IARM event with code {event_code} should be sent
# Event codes:
# MAINT_RFC_COMPLETE = 2
# MAINT_RFC_ERROR = 3
# MAINT_REBOOT_REQUIRED = 4
Feature Enable/Disable Pattern
Scenario: Feature enable via HTTP 200 response
Given the XConf server returns a 200 with feature configuration
When the rfcMgr binary is executed
Then the feature parameters should be applied to the TR-181 store
Scenario: No change via HTTP 304 response
Given the configSetHash matches the cached value
When the rfcMgr binary is executed
Then no parameters should be changed
And the log should contain "304"
RFC Properties Override Pattern
Scenario: Override XConf URL via rfc.properties
Given "/opt/rfc.properties" contains "RFC_CONFIG_SERVER_URL={override_url}"
When the rfcMgr binary is executed
Then the XConf request should use "{override_url}" instead of the default
Negative Test Pattern
Scenario: Unresolvable XConf hostname
Given RFC_XCONF_URL points to "https://unmockxconf:50053/featureControl/getSettings"
When the rfcMgr binary is executed
Then the log should contain a DNS resolution failure
And the rfcMgr should exit with an error
Scenario: Missing rfc.properties file
Given "/etc/rfc.properties" does not exist
When the rfcMgr binary is executed
Then the log should indicate a configuration error
Quality Checklist
Before completing feature generation for RFC Manager:
All rfcMgr/ source files analyzed for behavioral scenarios
Test runner:pytest executed sequentially by run_l2.sh and run_l2_reboot_trigger.sh.
Interfaces exercised:tr181 CLI (parameter SET/GET), mock parodus binary (WebPA), mock XConf HTTPS server (rfcData.js), log scraping (/opt/logs/rfcscript.txt).
Example: Complete RFC Manager Feature File
####################################################################################
# If not stated otherwise in this file or this component's Licenses.txt file the
# following copyright and licenses apply:
#
# Copyright 2025 RDK Management
#
# Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at
#
# http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.
####################################################################################
# Source: rfcMgr/rfc_xconf_handler.cpp, rfcMgr/xconf_handler.cpp
# Test: test/functional-tests/tests/test_rfc_xconf_communication.py
@order-4
Feature: RFC Manager XConf Communication
Background:
Given the rfcMgr binary is available at "/usr/bin/rfcMgr"
And the mock XConf HTTPS server is running on port 50053
And the RFC properties file exists at "/etc/rfc.properties"
And the route file "/tmp/route_available" exists
And the DNS file "/etc/resolv.dnsmasq" contains valid entries
Scenario: Successful XConf request with feature data (HTTP 200)
Given RFC_CONFIG_SERVER_URL is set to "https://mockxconf:50053/featureControl/getSettings"
When the rfcMgr binary is executed
Then the log should contain "HTTP Response code: 200"
And the file "/opt/secure/RFC/tr181store.ini" should contain applied parameters
Scenario: No configuration change (HTTP 304)
Given the cached configSetHash matches the server value
And RFC_CONFIG_SERVER_URL is set to "https://mockxconf:50053/featureControl304/getSettings"
When the rfcMgr binary is executed
Then the log should contain "HTTP Response code: 304"
And the TR-181 store should remain unchanged
Scenario: XConf server returns error (HTTP 404)
Given RFC_CONFIG_SERVER_URL is set to "https://mockxconf:50053/featureControl404/getSettings"
When the rfcMgr binary is executed
Then the log should contain "HTTP Response code: 404"
And no parameters should be applied
Integration with Gap Analysis
After generating feature files, use them for gap analysis against the L2 test suite:
Count total scenarios (= total testable behaviors)
Count scenarios that have a matching test_* function in test/functional-tests/tests/
Calculate coverage = matched / total
Step 3: Identify Missing Tests
Features without test coverage fall into categories:
Category
Example
Required Infrastructure
Untested error paths
XConf timeout, curl errors
Mock server error injection
Platform-specific checks
RDKB dmcli, RDKC getifaddrs
Platform-specific Docker build
Retry/backoff logic
XConf retry on failure
Configurable mock server delays
Cron job management
manageCronJob()
Cron mock or verification
IARM event edge cases
Multiple events, race conditions
IARM bus mock verification
mTLS certificate tests
Dynamic P12, static PEM
Certificate infrastructure
Step 4: Identify Undocumented Tests
Tests that exist in test/functional-tests/tests/ but have no matching scenario in
test/functional-tests/features/. These should be documented retroactively.
Step 5: Generate Gap Report
Include a summary table in test/docs/L2_Analysis_Report.md:
