ARTICLE DETAIL

资讯详情

深耕郑州网站建设与运营推广的一线实战洞察。

ESP-IDF NVS 主机端测试指南:在 Linux 上构建、运行 nvs_host_test 并生成代码覆盖率报告

ESP-IDF NVS 主机端测试指南:在 Linux 上构建、运行 nvs_host_test 并生成代码覆盖率报告 ESP-IDF NVS 主机端测试指南在 Linux 上构建、运行 nvs_host_test 并生成代码覆盖率报告【免费下载链接】esp-idfEspressif IoT Development Framework. Official development framework for Espressif SoCs.项目地址: https://gitcode.com/GitHub_Trending/es/esp-idf在 ESP-IDF 中NVSNon-Volatile Storage非易失性存储组件负责在 Flash 分区上实现键值存储。components/nvs_flash/host_test/nvs_host_test是一个专为Linux 主机环境设计的测试应用它不依赖真实硬件而是通过 FreeRTOS mock、内存块设备ramdisk和 Catch2 测试框架在 PC 上直接对 NVS 核心逻辑进行单元测试。读完本文你将能够在 Linux 上正确构建该测试应用、理解其配置与测试组织结构、本地运行全部测试用例、通过 CI 的多种配置组合验证 NVS并生成components/nvs_flash组件的代码覆盖率报告。测试应用的整体结构在展开操作步骤之前先了解这个测试应用的组织方式有助于理解后面每一步命令的作用。从源码结构看nvs_host_test是一个标准的 ESP-IDF 工程CMakeLists.txt其关键特征如下目标平台固定为 Linux由 sdkconfig.defaults 中CONFIG_IDF_TARGETlinux决定该测试应用属于 Supported Targets: Linux。使用 FreeRTOS mock 而非真实 RTOS顶层 CMake 中通过EXTRA_COMPONENT_DIRS引入$IDF_PATH/tools/mocks/freertos/注释明确说明 This test app doesntrequire FreeRTOS, using mock instead。测试用例基于 Catch2main/idf_component.yml 声明了espressif/catch2: ^3.4.0依赖由于 Linux 目标下main入口通常由 freertos 组件提供这里通过链接Catch2WithMain让 Catch2 提供main函数。直接复用 NVS 组件源码main/CMakeLists.txt 将nvs_flash/src、nvs_flash/private_include加入包含路径并REQUIRES nvs_flash、PRIV_REQUIRES spi_flash同时设置WHOLE_ARCHIVE保证静态库符号完整保留。测试覆盖面广main组件下包含多组测试文件分别验证不同层面的 NVS 功能test_nvs.cppNVS 基本读写、命名空间等核心 APItest_nvs_cxx_api.cppC 风格接口test_nvs_handle.cpp句柄handleAPItest_nvs_initialization.cpp初始化与迭代器行为test_nvs_storage.cpp存储层加密/扇区擦除逻辑test_partition_manager.cpp分区管理bdl_ramdisk.cpp实现了一个基于内存的块设备blockdev ramdisk使 NVS 加密等依赖esp_blockdev的存储路径可以在无硬件环境下运行test_fixtures.cpp测试夹具负责分区表与块设备的初始化。此外main组件还显式添加了--coverage编译与链接选项这是后文生成覆盖率报告的前提。构建测试应用官方推荐的构建流程来自 README如下先激活 IDF 环境进入测试应用目录设置目标平台为 Linux然后执行构建。cd $IDF_PATH . ./export.sh cd components/nvs_flash/host_test/nvs_host_test idf.py --preview set-target linux idf.py build两点说明idf.py --preview set-target linux中的--preview表明 Linux 主机目标在当前仓库版本中仍属于预览preview阶段的目标使用时需注意其稳定性边界。构建时会应用 sdkconfig.defaults 中的默认配置其中与测试行为直接相关的项包括配置项取值作用CONFIG_IDF_TARGETlinux固定目标平台为 Linux 主机CONFIG_COMPILER_CXX_EXCEPTIONSy启用 C 异常测试代码为 CCONFIG_UNITY_ENABLE_IDF_TEST_RUNNERn不启用 Unity 测试 runner本应用使用 Catch2CONFIG_ESP_PARTITION_ENABLE_STATSy启用分区统计信息供分区管理测试断言使用CONFIG_PARTITION_TABLE_CUSTOMy使用自定义分区表文件CONFIG_PARTITION_TABLE_CUSTOM_FILENAMEpartitions_nvs_host_test.csv指定测试专用分区表CONFIG_PARTITION_TABLE_OFFSET0x8000分区表偏移对应的自定义分区表 partitions_nvs_host_test.csv 内容如下其中三个 NVS 数据分区分别用于普通、加密等不同的存储测试场景# Name, Type, SubType, Offset, Size, Flags # Note: if you have increased the bootloader size, make sure to update the offsets to avoid overlap nvs, data, nvs, , 0xa000, nvs_sec, data, nvs, , 0xa000, nvs_3sec, data, nvs, , 0x3000, phy_init, data, phy, , 0x1000, factory, app, factory, , 1M,构建完成后可执行文件位于build/nvs_host_test.elf。本地运行测试运行步骤来自 README 的官方说明cd $IDF_PATH ./components/nvs_flash/host_test/nvs_host_test/build/nvs_host_test.elfREADME 特别强调必须回到 IDF 根目录再运行该二进制。原因是测试用例内部存在若干基于相对路径的文件访问工作目录不对会导致这些相对路径解析失败。README 同时说明这是 CI 管线的一个已知限制——当时无法为 host 测试指定工作目录因此在 CI 之外本地复现时务必遵守上述运行位置约定。测试全部通过时输出中会出现All tests passed这也是 CI 判定通过的依据见下一节。CI 中的多配置运行方式CI 并不直接裸跑二进制而是通过 pytest_nvs_host_linux.py 使用 pytest-embedded 框架驱动测试应用pytest.mark.host_test pytest.mark.parametrize( config, [ default_set_key, legacy_set_key, esp_blockdev, ], indirectTrue, ) pytest.mark.parametrize(target, [linux], indirect[target]) def test_nvs_host_linux(dut: Dut) - None: dut.expect_exact(All tests passed, timeout60)parametrize列出了三种构建配置各自对应一份 sdkconfig 片段用于覆盖 NVS 不同的运行形态配置名对应文件覆盖场景default_set_keysdkconfig.ci.default_set_key默认行为显式CONFIG_NVS_LEGACY_DUP_KEYS_COMPATIBILITYn关闭旧版重复键兼容legacy_set_keysdkconfig.ci.legacy_set_keyCONFIG_NVS_LEGACY_DUP_KEYS_COMPATIBILITYy验证对旧版本重复键dup key数据的兼容逻辑esp_blockdevsdkconfig.ci.esp_blockdevCONFIG_NVS_BDL_STACKyNVS 内部改走esp_blockdev存储栈而非直接调用esp_partitionAPI与main/bdl_ramdisk.cpp提供的内存块设备配合验证加密 NVS 的块设备路径判定逻辑很直接在 60 秒内等待到精确输出All tests passed即视为该配置下全部用例通过。三种配置组合起来意味着同一套测试用例会在 默认/兼容旧键/块设备存储栈 三个维度上分别回归。生成代码覆盖率报告README 提供了生成覆盖率报告的官方命令cd components/nvs_flash/host_test/nvs_host_test idf.py build coverage open ./build/coverage_report/index.html这条命令能工作依赖顶层 CMakeLists.txt 中定义的两个 CMake 机制coverage自定义目标add_custom_target(coverage ...)其依赖coverage_report/index.html生成规则idf.py build coverage实际会触发gcovr生成 HTML 报告关键参数为--root $IDF_PATH/components/nvs_flash报告以 NVS 组件为根聚焦被测试组件而非整个工程--html-details输出逐文件的详细 HTML 报告--exclude .../managed_components/*排除通过组件管理器拉取的第三方依赖如 Catch2输出到${CMAKE_CURRENT_BINARY_DIR}/coverage_report/index.html即build/coverage_report/index.html。同时main/CMakeLists.txt 中对main组件强制开启--coverage编译与链接选项保证nvs_flash组件中的目标代码在测试运行时产生 gcov 数据文件。此外顶层 CMake 还定义了NO_DEBUG_STORAGE宏用于裁剪测试中不需要的调试存储路径。生成完成后用浏览器打开./build/coverage_report/index.html即可查看components/nvs_flash组件逐文件的行覆盖与分支覆盖明细。小结nvs_host_test展示了 ESP-IDF 主机端组件测试的一个完整范式以idf.py --preview set-target linuxidf.py build在无硬件环境完成构建用 FreeRTOS mocktools/mocks/freertos替代 RTOS用内存块设备bdl_ramdisk替代 Flash使 NVS 的加密存储、分区管理等核心逻辑可在 PC 上被 Catch2 用例完整覆盖运行二进制必须回到$IDF_PATH根目录以正确解析测试内的相对路径CI 通过 pytest_nvs_host_linux.py 在default_set_key、legacy_set_key、esp_blockdev三种配置下回归并以All tests passed输出作为通过判据借助 CMake 内置的coverage目标与gcovr一条idf.py build coverage即可获得 NVS 组件的 HTML 覆盖率报告便于维护者在改动 NVS 源码时评估测试覆盖情况。【免费下载链接】esp-idfEspressif IoT Development Framework. Official development framework for Espressif SoCs.项目地址: https://gitcode.com/GitHub_Trending/es/esp-idf创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
返回列表