bdd-feature-generator

BDD Feature Generator for tr69hostif

Purpose

Automatically generate BDD feature files in Gherkin format by analyzing the tr69hostif source code. This skill creates comprehensive behavioral documentation that can serve as:

• Functional documentation of TR-181 data model parameter handlers (GET/SET)
• Test specifications for L2 functional tests (test/functional-tests/)
• Requirements traceability linking handler source code to observable behavior
• Gap analysis baseline for comparing L2 tests vs implemented handlers

Usage

Invoke this skill when:

• Documenting existing tr69hostif parameter handlers in BDD format
• Creating test specifications for new TR-181 parameters
• Generating feature files for untested profiles (WiFi, MoCA, Ethernet, etc.)
• Performing gap analysis between L2 tests and source implementation
• Onboarding new team members with behavioral documentation of the daemon

Project Context

tr69hostif is a TR-069/TR-181 host interface daemon for RDK devices. It:

• Exposes ~708 TR-181 parameters via rbus DML and HTTP/WDMP-C interfaces
• Communicates with Parodus/WebPA for cloud management
• Calls Thunder JSON-RPC plugins for device state (NetworkManager, AuthService, etc.)
• Manages RFC, Bootstrap, and Non-RFC parameter stores backed by INI files
• Runs as a systemd service with multiple initialization threads

Prerequisites

Before running this skill:

1. Review the build system — src/Makefile.am and src/hostif/profiles/Makefile.am
2. Identify compiled profiles — Only document profiles that are actually built
3. Review existing feature files — Match the format in docs/features/ and test/functional-tests/features/
4. Check existing coverage — Read test/docs/L2_Test_Coverage.md for current gap data
5. Understand test interfaces — L2 tests use rbuscli (rbus DML), mock parodus binary (WebPA), and log scraping

Process

Step 1: Analyze Build Configuration

The tr69hostif build is Autotools-based. Identify compiled components from the Makefile chain:

# Top-level: identifies src/ as the main SUBDIR
cat Makefile.am | grep "SUBDIRS"
# → SUBDIRS = $(SUBDIRS_MOCA) $(SUBDIRS_WIFI) src

# Source level: identifies compiled subsystems
cat src/Makefile.am | grep "SUBDIRS"
# → SUBDIRS = hostif/handlers hostif/profiles
# → SUBDIRS += hostif/parodusClient
# → SUBDIRS += hostif/httpserver         (if !WITH_NEW_HTTP_SERVER_DISABLE)

# Profile level: identifies compiled TR-181 profile directories
cat src/hostif/profiles/Makefile.am | grep "SUBDIRS"
# → SUBDIRS = STBService Device DeviceInfo Ethernet IP Time
# → SUBDIRS += DHCPv4          (if WITH_DHCP_PROFILE)
# → SUBDIRS += StorageService   (if WITH_STORAGESERVICE_PROFILE)
# → SUBDIRS += InterfaceStack   (if WITH_INTFSTACK_PROFILE)
# → SUBDIRS += wifi             (if WITH_WIFI_PROFILE)

Always compiled profiles:

Profile Directory	TR-181 Namespace	Key Source Files
profiles/STBService/	Device.Services.STBService.*	Components_AudioOutput.cpp, Components_HDMI.cpp, Components_XrdkEMMC.cpp, etc.
profiles/Device/	Device.* (x_rdk)	x_rdk_profile.cpp
profiles/DeviceInfo/	Device.DeviceInfo.*	Device_DeviceInfo.cpp, XrdkBlueTooth.cpp, XrdkCentralComRFC.cpp, XrdkCentralComBSStore.cpp
profiles/Ethernet/	Device.Ethernet.*	Device_Ethernet_Interface.cpp, Device_Ethernet_Interface_Stats.cpp
profiles/IP/	Device.IP.*	Device_IP.cpp, Device_IP_Interface.cpp, Device_IP_Interface_IPv4Address.cpp, Device_IP_Interface_IPv6Address.cpp, Device_IP_Interface_Stats.cpp
profiles/Time/	Device.Time.*	Device_Time.cpp

Conditionally compiled profiles:

Profile Directory	Build Flag	TR-181 Namespace
profiles/DHCPv4/	WITH_DHCP_PROFILE	Device.DHCPv4.*
profiles/StorageService/	WITH_STORAGESERVICE_PROFILE	Device.StorageService.*
profiles/InterfaceStack/	WITH_INTFSTACK_PROFILE	Device.InterfaceStack.*
profiles/wifi/	WITH_WIFI_PROFILE	Device.WiFi.*

Always compiled non-profile components:

Component	Key Source Files	Purpose
handlers/	hostIf_rbus_Dml_Provider.cpp, hostIf_msgHandler.cpp, hostIf_jsonReqHandlerThread.cpp, etc.	Request routing, rbus DML registration
parodusClient/	Parodus/WebPA client	Cloud management interface
httpserver/ (conditional)	http_server.cpp, request_handler.cpp, XrdkCentralComRFCVar.cpp	libsoup HTTP server for WDMP-C JSON

Exclude from feature generation:

• src/hostif/include/ — Headers only
• src/hostif/handlers/src/gtest/, src/hostif/profiles/*/gtest/ — Unit tests (L1)
• src/hostif/*/docs/ — Existing documentation
• test/ — Test infrastructure
• scripts/ — Build/validation utilities

Step 2: Analyze Source Code Structure

For each compiled profile/component:

1. Read the header file (.h) — Identify all get_* and set_* handler declarations
2. Read the implementation (.cpp) — Extract TR-181 parameter names from string comparisons, Thunder plugin calls, file I/O paths
3. Identify the request handler — Map the profile to its hostIf_*_ReqHandler.cpp in handlers/src/
4. Note conditional compilation — #ifdef USE_WIFI_PROFILE, #ifdef BLE_TILE_PROFILE, etc.
5. Note Thunder dependencies — Any JSONRPCLink or org.rdk.* plugin invocations
6. Note file-backed parameters — INI files, RFC stores, /opt/secure/RFC/ paths

Key elements to extract for each profile:

Element	Where to Find	Example
GET handler functions	.h class declaration	get_Device_DeviceInfo_ModelName()
SET handler functions	.h class declaration	set_Device_DeviceInfo_X_RDKCENTRAL_COM_FirmwareToDownload()
TR-181 parameter paths	.cpp string comparisons	"Device.DeviceInfo.ModelName"
Thunder plugin calls	.cpp Invoke() calls	org.rdk.NetworkManager.GetIPSettings
File-backed state	.cpp file open/write	/opt/secure/RFC/bootstrap.ini
Error return codes	.cpp return statements	NOK, OK
Compile guards	.h / .cpp #ifdef	USE_WIFI_PROFILE, BLE_TILE_PROFILE

Step 3: Create Feature File Structure

Feature files are generated to docs/features/.

mkdir -p docs/features

Naming convention for tr69hostif:

Source	Feature File	Description
profiles/DeviceInfo/	deviceinfo_parameters.feature	DeviceInfo standard + custom params
profiles/DeviceInfo/XrdkBlueTooth.cpp	bluetooth_parameters.feature	BLE/Tile parameters
profiles/IP/	ip_interface.feature	IP, IPv4Address, IPv6Address, Stats
profiles/Ethernet/	ethernet_interface.feature	Ethernet interface + stats
profiles/wifi/	wifi_parameters.feature	WiFi Radio, SSID, AccessPoint, EndPoint
profiles/moca/	moca_interface.feature	MoCA interface, stats, QoS, mesh
profiles/Time/	time_parameters.feature	Time, NTP, Chrony
profiles/STBService/	stbservice_components.feature	AudioOutput, HDMI, eMMC, SDCard, etc.
profiles/StorageService/	storage_service.feature	PhysicalMedium
profiles/DHCPv4/	dhcpv4_client.feature	DHCPv4 client params
profiles/InterfaceStack/	interface_stack.feature	HigherLayer/LowerLayer
handlers/src/hostIf_rbus_Dml_Provider.cpp	rbus_dml_registration.feature	rbus data element registration
httpserver/	http_server.feature	WDMP-C HTTP server protocol
parodusClient/	webpa_parodus.feature	WebPA/Parodus communication
Daemon lifecycle	bootup_sequence.feature	Init, threads, shutdown
RFC/Bootstrap stores	rfc_store.feature	RFC, Bootstrap, rfcVariable persistence

Step 4: Generate Feature Files

Use this template for tr69hostif 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: src/hostif/profiles/{ProfileDir}/{SourceFile}.cpp

Feature: {TR-181 Namespace} Parameter Handlers

  Background:
    Given the tr69hostif daemon is running and initialized
    And rbuscli is available on the system

  Scenario: GET {TR-181 Parameter Path}
    When I GET "{parameter.path}" via rbus
    Then the rbus response should not contain an error
    And the rbus response should contain a valid value

  Scenario: SET and GET {TR-181 Parameter Path}
    When I SET "{parameter.path}" to "{test_value}" as {type} via rbus
    And I GET "{parameter.path}" via rbus
    Then the rbus response should not contain an error
    And the rbus response should contain "{test_value}"

Step 5: Map Handler Code to Scenarios

For each TR-181 parameter handler, create scenarios covering:

1. GET happy path — Normal successful GET returning expected value
2. SET + GET roundtrip — SET a value, GET it back, verify match (for writable params)
3. Error conditions — GET/SET on invalid instance, wrong data type
4. File-backed persistence — Verify SET writes to INI file (for RFC/Bootstrap params)
5. **Thunder

---

Content truncated.