Cover Agent 测试数据库指南用 SQLite 记录与查询 AI 生成测试的每次尝试【免费下载链接】cover-agentQodo-Cover: An AI-Powered Tool for Automated Test Generation and Code Coverage Enhancement! 项目地址: https://gitcode.com/GitHub_Trending/co/cover-agentCover Agent 在迭代生成测试用例时会把每一次「生成 → 运行 → 判定」的尝试完整写入本地 SQLite 数据库便于事后追溯 AI 写了什么测试、为什么失败、产生了怎样的改动。本篇基于 docs/database_usage.md 展开介绍如何配置并运行带--log-db-path的 Cover Agent、如何在集成测试中把同一个数据库传入 Docker 容器以及如何用sqlite3或 HTML 报告查询表unit_test_generation_attempts中的数据读完后你将能够独立搭建这套测试日志库并理解其背后的 SQLAlchemy 模型、写入时机与报告生成链路。功能定位与前置要求该功能目前仍处于 beta 阶段。数据库的作用是为 Cover Agent 的测试生成过程提供结构化持久化每一次尝试的通过/失败状态、退出码、标准输出/错误、生成的测试代码与新增 import 都会落库从而把原本散落在终端输出和日志文件里的过程信息变成可查询的数据。当前版本的要求如下仅支持 SQLite。SQLite 以本地.db文件读写不需要数据库服务器底层基于 SQLAlchemy 实现长期目标是支持任何 SQLAlchemy 支持的关系型数据库这一点在 docs/database_usage.md 中作为规划说明开始使用前可以用touch命令先创建一个空.db文件touch run_tests.db实际上不提前创建文件也可以SQLAlchemy 的create_engineBase.metadata.create_all会在首次连接时自动建表建文件。提前touch只是文档给出的最小化起步方式。命令行参数--log-db-path与LOG_DB_PATH环境变量Cover Agent 通过--log-db-path选项接收数据库路径。参数解析逻辑在 cover_agent/main.py 中优先级为环境变量LOG_DB_PATH 配置文件 命令行默认值# Accepts from environment variables first log_db_path os.getenv(LOG_DB_PATH) or settings.get(log_db_path) ... ( --log-db-path, dict(typestr, defaultlog_db_path, helpPath to optional log database. Default: %(default)s.), ),默认值来自 cover_agent/settings/configuration.tomllog_db_path cover_agent_unit_test_runs.db report_filepath test_results.htmlcover_agent/settings/README.md 对这两项的配置说明为log_db_path: SQLite 日志数据库的路径与文件名默认cover_agent_unit_test_runs.dbreport_filepath: HTML 测试报告的路径与文件名默认test_results.html在 cover_agent/settings/config_schema.py 中配置项最终同样遵循「环境变量优先」的规则log_db_pathos.getenv(LOG_DB_PATH) or args.log_db_path。一个可直接运行的完整示例以下命令以仓库自带的 Python FastAPI 模板项目为例完整保留了原文档中的所有参数cover-agent \ --source-file-path templated_tests/python_fastapi/app.py \ --test-file-path templated_tests/python_fastapi/test_app.py \ --code-coverage-report-path templated_tests/python_fastapi/coverage.xml \ --test-command pytest --cov. --cov-reportxml --cov-reportterm \ --test-command-dir templated_tests/python_fastapi \ --coverage-type cobertura \ --desired-coverage 70 \ --max-iterations 10 \ --suppress-log-files \ --log-db-path run_tests.db各参数含义参数说明--source-file-path被测源文件路径--test-file-path输入测试文件路径--code-coverage-report-path覆盖率报告文件路径--test-command运行测试并生成覆盖率报告的命令--test-command-dir测试命令的执行目录默认为当前目录--coverage-type覆盖率报告类型如cobertura--desired-coverage目标覆盖率百分比--max-iterations最大迭代次数--log-db-path可选日志数据库路径本功能的核心开关运行后Cover Agent 会在数据库中创建名为unit_test_generation_attempts的表。注意--suppress-log-files与数据库的关系上例沿用了原文档的写法同时带--suppress-log-files但从源码结构看两者存在冲突需要注意在 cover_agent/cover_agent.py 中数据库连接的建立受generate_log_files开关控制# Connect to the test DB if self.generate_log_files: self.test_db UnitTestDB(db_connection_stringfsqlite:///{self.config.log_db_path})而generate_log_files not config.suppress_log_files。也就是说加上--suppress-log-files后CLI 帮助文本所述的「抑制所有生成的日志文件HTML、logs、DB 文件」会生效数据库不会被初始化--log-db-path也就不会写入数据。如果目标是收集数据库记录运行命令时应去掉--suppress-log-files。核心实现UnitTestDB与unit_test_generation_attempts表数据库逻辑集中在 cover_agent/unit_test_db.py。SQLAlchemy 模型定义了完整的表结构class UnitTestGenerationAttempt(Base): __tablename__ unit_test_generation_attempts id Column(Integer, primary_keyTrue) run_time Column(DateTime, defaultdatetime.now) # Use local time status Column(String) reason Column(Text) exit_code Column(Integer) stderr Column(Text) stdout Column(Text) test_code Column(Text) imports Column(Text) language Column(String) prompt Column(Text) source_file Column(Text) original_test_file Column(Text) processed_test_file Column(Text)相比原文档PRAGMA table_info展示的 9 个基础列id、run_time、status、reason、exit_code、stderr、stdout、test_code、imports当前模型的 schema 更丰富还额外记录了language、prompt本轮发给模型的提示词、source_file、original_test_file与processed_test_file改动前后的完整测试文件内容。这意味着库里保存的不只是「结果」还包括「输入」可以直接复盘每一次 AI 调用的上下文。UnitTestDB类提供了三个关键方法__init__(db_connection_string)创建引擎并执行Base.metadata.create_all(self.engine)自动建表再用scoped_session(sessionmaker(bindengine))建立会话工厂insert_attempt(test_result)将一次验证结果字典映射到模型字段后session.add并提交返回新记录的主键idget_all_attempts()/dump_to_report(report_filepath)读出全部记录并交给ReportGenerator生成 HTML 报告。写入时机验证后的每条结果在 cover_agent/cover_agent.py 的主循环中每当一轮生成的测试完成验证validate_test对每个新生成的测试逐条判定 PASS/FAIL后就会逐条入库# Insert results into database if self.has_test_db(): for result in test_results: result[prompt] self.test_gen.prompt self.test_db.insert_attempt(result)可以看到写入前会把本轮使用的提示词self.test_gen.prompt附加进结果字典——这正是表中prompt列的来源。而运行结束时# Only generate report if file generation is enabled if self.generate_log_files: # Generate report and cleanup self.test_db.dump_to_report(self.config.report_filepath)会把整个数据库的内容渲染成 HTML 报告默认test_results.html。cover_agent/report_generator.py 中的ReportGenerator.generate_report使用 Jinja2 模板渲染一张包含 Status、Reason、Exit Code、Language、Modified Test File原始与处理后文件的逐行 diff和 DetailsSTDERR/STDOUT/Test Code/Imports的表格因此 HTML 报告本质上就是unit_test_generation_attempts表的可读视图。独立导出报告的 CLI 入口unit_test_db.py末尾还提供了一个模块级函数与 CLI允许不运行 Cover Agent 主流程、直接从已有数据库导出报告def dump_to_report(path_to_dbcover_agent_unit_test_runs.db, report_filepathtest_results.html): unittest_db UnitTestDB(fsqlite:///{path_to_db}) unittest_db.dump_to_report(report_filepath) def dump_to_report_cli(): parser argparse.ArgumentParser(descriptionGenerate a unit test report.) parser.add_argument(--path-to-db, ...) parser.add_argument(--report-filepath, ...)参数--path-to-db默认cover_agent_unit_test_runs.db--report-filepath默认test_results.html。对应测试见 tests/test_unit_test_db.py其中test_dump_to_report_cli_custom_args用monkeypatch替换sys.argv验证自定义路径下的报告生成test_dump_to_report_defaults验证默认路径行为test_dump_to_report则断言生成的 HTML 中确实包含插入的测试代码与测试文件内容。在集成测试中复用同一个数据库仓库的集成测试套件tests_integration也原生支持把同一个.db文件注入每个 Docker 容器。在仓库根目录执行LOG_DB_PATHfull_path_to_root_folder/run_tests.db tests_integration/test_all.sh其工作机制是tests_integration/test_all.sh 读取环境变量并转换为参数# Set the log_db_arg variable if LOG_DB_PATH is set log_db_arg if [ -n $LOG_DB_PATH ]; then log_db_arg--log-db-path $LOG_DB_PATH fi随后把$log_db_arg追加到 C、C、C#、Go、Java Gradle、Java Spring、VanillaJS、Python FastAPI、React、Ruby Sinatra、TypeScript 等全部 11 个场景的调用中。tests_integration/test_with_docker.sh 负责真正的容器编排先把宿主机上的数据库文件挂载进容器再在容器内以挂载点路径传给cover-agentif [ -n $LOG_DB_PATH ]; then LOG_DB_NAME$(basename $LOG_DB_PATH) ARGS$ARGS --volume $LOG_DB_PATH:/$LOG_DB_NAME fi ... if [ -n $LOG_DB_PATH ]; then COMMAND$COMMAND --log-db-path \/$LOG_DB_NAME\ fi这种「宿主机路径 → 容器内根目录同名文件」的映射方式取basename作为容器内路径使得来自不同语言、不同 Docker 镜像的多次运行结果最终都汇聚到同一个 SQLite 文件里方便跨项目对比各场景的生成质量。查询与观察测试数据运行完成后可以用外部数据库图形化工具或 SQLite 命令行客户端查看结果sqlite3 run_tests.db进入 sqlite3 后先列出所有表可以看到unit_test_generation_attempts已被创建sqlite .tables unit_test_generation_attempts查看表结构原文档输出的字段列表sqlite PRAGMA table_info(unit_test_generation_attempts); 0|id|INTEGER|1||1 1|run_time|DATETIME|0||0 2|status|VARCHAR|0||0 3|reason|TEXT|0||0 4|exit_code|INTEGER|0||0 5|stderr|TEXT|0||0 6|stdout|TEXT|0||0 7|test_code|TEXT|0||0 8|imports|TEXT|0||0提示如前所述当前版本的 SQLAlchemy 模型在 9 个基础列之外还包含language、prompt、source_file、original_test_file、processed_test_file等列实际PRAGMA table_info输出会比上表更长。常用查询示例-- 查看全部测试结果含格式化换行命令行下可能不易读GUI 更佳 select * from unit_test_generation_attempts; -- 只筛选失败的测试 select * from unit_test_generation_attempts where status FAIL;由于stdout、stderr、test_code等列包含多行文本与转义换行直接在终端里读select *会比较吃力实践中更推荐两类方式使用数据库 GUI 工具浏览宽表直接调用前文提到的报告导出能力生成 HTML 报告ReportGenerator会对状态着色PASS 绿 / FAIL 红并折叠展示完整 diff 与 stderr/stdout/test code/imports比裸 SQL 输出更易读。小结与适用前提该功能为 beta当前仅支持 SQLite 本地文件数据库连接串以sqlite:///前缀在源码中拼接长期目标是随 SQLAlchemy 扩展到其他数据库类型。启用方式--log-db-path命令行参数或LOG_DB_PATH环境变量环境变量优先默认值cover_agent_unit_test_runs.db来自 cover_agent/settings/configuration.toml。写入链路CoverAgent验证每轮生成的测试后通过 cover_agent/unit_test_db.py 的insert_attempt逐条落库运行结束时通过dump_to_report渲染 cover_agent/report_generator.py 的 HTML 报告。集成测试可通过LOG_DB_PATH... tests_integration/test_all.sh把单一数据库文件挂载进所有 Docker 场景实现跨项目数据汇聚。注意不要同时使用--suppress-log-files与--log-db-path在需要落库时因为源码中数据库的初始化与报告生成都以generate_log_files为前置条件。单测 tests/test_unit_test_db.py 覆盖了插入、查询、报告导出与 CLI 参数四条链路可作为理解该模块行为的最佳「活文档」。【免费下载链接】cover-agentQodo-Cover: An AI-Powered Tool for Automated Test Generation and Code Coverage Enhancement! 项目地址: https://gitcode.com/GitHub_Trending/co/cover-agent创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Cover Agent 测试数据库指南用 SQLite 记录与查询 AI 生成测试的每次尝试【免费下载链接】cover-agentQodo-Cover: An AI-Powered Tool for Automated Test Generation and Code Coverage Enhancement! 项目地址: https://gitcode.com/GitHub_Trending/co/cover-agentCover Agent 在迭代生成测试用例时会把每一次「生成 → 运行 → 判定」的尝试完整写入本地 SQLite 数据库便于事后追溯 AI 写了什么测试、为什么失败、产生了怎样的改动。本篇基于 docs/database_usage.md 展开介绍如何配置并运行带--log-db-path的 Cover Agent、如何在集成测试中把同一个数据库传入 Docker 容器以及如何用sqlite3或 HTML 报告查询表unit_test_generation_attempts中的数据读完后你将能够独立搭建这套测试日志库并理解其背后的 SQLAlchemy 模型、写入时机与报告生成链路。功能定位与前置要求该功能目前仍处于 beta 阶段。数据库的作用是为 Cover Agent 的测试生成过程提供结构化持久化每一次尝试的通过/失败状态、退出码、标准输出/错误、生成的测试代码与新增 import 都会落库从而把原本散落在终端输出和日志文件里的过程信息变成可查询的数据。当前版本的要求如下仅支持 SQLite。SQLite 以本地.db文件读写不需要数据库服务器底层基于 SQLAlchemy 实现长期目标是支持任何 SQLAlchemy 支持的关系型数据库这一点在 docs/database_usage.md 中作为规划说明开始使用前可以用touch命令先创建一个空.db文件touch run_tests.db实际上不提前创建文件也可以SQLAlchemy 的create_engineBase.metadata.create_all会在首次连接时自动建表建文件。提前touch只是文档给出的最小化起步方式。命令行参数--log-db-path与LOG_DB_PATH环境变量Cover Agent 通过--log-db-path选项接收数据库路径。参数解析逻辑在 cover_agent/main.py 中优先级为环境变量LOG_DB_PATH 配置文件 命令行默认值# Accepts from environment variables first log_db_path os.getenv(LOG_DB_PATH) or settings.get(log_db_path) ... ( --log-db-path, dict(typestr, defaultlog_db_path, helpPath to optional log database. Default: %(default)s.), ),默认值来自 cover_agent/settings/configuration.tomllog_db_path cover_agent_unit_test_runs.db report_filepath test_results.htmlcover_agent/settings/README.md 对这两项的配置说明为log_db_path: SQLite 日志数据库的路径与文件名默认cover_agent_unit_test_runs.dbreport_filepath: HTML 测试报告的路径与文件名默认test_results.html在 cover_agent/settings/config_schema.py 中配置项最终同样遵循「环境变量优先」的规则log_db_pathos.getenv(LOG_DB_PATH) or args.log_db_path。一个可直接运行的完整示例以下命令以仓库自带的 Python FastAPI 模板项目为例完整保留了原文档中的所有参数cover-agent \ --source-file-path templated_tests/python_fastapi/app.py \ --test-file-path templated_tests/python_fastapi/test_app.py \ --code-coverage-report-path templated_tests/python_fastapi/coverage.xml \ --test-command pytest --cov. --cov-reportxml --cov-reportterm \ --test-command-dir templated_tests/python_fastapi \ --coverage-type cobertura \ --desired-coverage 70 \ --max-iterations 10 \ --suppress-log-files \ --log-db-path run_tests.db各参数含义参数说明--source-file-path被测源文件路径--test-file-path输入测试文件路径--code-coverage-report-path覆盖率报告文件路径--test-command运行测试并生成覆盖率报告的命令--test-command-dir测试命令的执行目录默认为当前目录--coverage-type覆盖率报告类型如cobertura--desired-coverage目标覆盖率百分比--max-iterations最大迭代次数--log-db-path可选日志数据库路径本功能的核心开关运行后Cover Agent 会在数据库中创建名为unit_test_generation_attempts的表。注意--suppress-log-files与数据库的关系上例沿用了原文档的写法同时带--suppress-log-files但从源码结构看两者存在冲突需要注意在 cover_agent/cover_agent.py 中数据库连接的建立受generate_log_files开关控制# Connect to the test DB if self.generate_log_files: self.test_db UnitTestDB(db_connection_stringfsqlite:///{self.config.log_db_path})而generate_log_files not config.suppress_log_files。也就是说加上--suppress-log-files后CLI 帮助文本所述的「抑制所有生成的日志文件HTML、logs、DB 文件」会生效数据库不会被初始化--log-db-path也就不会写入数据。如果目标是收集数据库记录运行命令时应去掉--suppress-log-files。核心实现UnitTestDB与unit_test_generation_attempts表数据库逻辑集中在 cover_agent/unit_test_db.py。SQLAlchemy 模型定义了完整的表结构class UnitTestGenerationAttempt(Base): __tablename__ unit_test_generation_attempts id Column(Integer, primary_keyTrue) run_time Column(DateTime, defaultdatetime.now) # Use local time status Column(String) reason Column(Text) exit_code Column(Integer) stderr Column(Text) stdout Column(Text) test_code Column(Text) imports Column(Text) language Column(String) prompt Column(Text) source_file Column(Text) original_test_file Column(Text) processed_test_file Column(Text)相比原文档PRAGMA table_info展示的 9 个基础列id、run_time、status、reason、exit_code、stderr、stdout、test_code、imports当前模型的 schema 更丰富还额外记录了language、prompt本轮发给模型的提示词、source_file、original_test_file与processed_test_file改动前后的完整测试文件内容。这意味着库里保存的不只是「结果」还包括「输入」可以直接复盘每一次 AI 调用的上下文。UnitTestDB类提供了三个关键方法__init__(db_connection_string)创建引擎并执行Base.metadata.create_all(self.engine)自动建表再用scoped_session(sessionmaker(bindengine))建立会话工厂insert_attempt(test_result)将一次验证结果字典映射到模型字段后session.add并提交返回新记录的主键idget_all_attempts()/dump_to_report(report_filepath)读出全部记录并交给ReportGenerator生成 HTML 报告。写入时机验证后的每条结果在 cover_agent/cover_agent.py 的主循环中每当一轮生成的测试完成验证validate_test对每个新生成的测试逐条判定 PASS/FAIL后就会逐条入库# Insert results into database if self.has_test_db(): for result in test_results: result[prompt] self.test_gen.prompt self.test_db.insert_attempt(result)可以看到写入前会把本轮使用的提示词self.test_gen.prompt附加进结果字典——这正是表中prompt列的来源。而运行结束时# Only generate report if file generation is enabled if self.generate_log_files: # Generate report and cleanup self.test_db.dump_to_report(self.config.report_filepath)会把整个数据库的内容渲染成 HTML 报告默认test_results.html。cover_agent/report_generator.py 中的ReportGenerator.generate_report使用 Jinja2 模板渲染一张包含 Status、Reason、Exit Code、Language、Modified Test File原始与处理后文件的逐行 diff和 DetailsSTDERR/STDOUT/Test Code/Imports的表格因此 HTML 报告本质上就是unit_test_generation_attempts表的可读视图。独立导出报告的 CLI 入口unit_test_db.py末尾还提供了一个模块级函数与 CLI允许不运行 Cover Agent 主流程、直接从已有数据库导出报告def dump_to_report(path_to_dbcover_agent_unit_test_runs.db, report_filepathtest_results.html): unittest_db UnitTestDB(fsqlite:///{path_to_db}) unittest_db.dump_to_report(report_filepath) def dump_to_report_cli(): parser argparse.ArgumentParser(descriptionGenerate a unit test report.) parser.add_argument(--path-to-db, ...) parser.add_argument(--report-filepath, ...)参数--path-to-db默认cover_agent_unit_test_runs.db--report-filepath默认test_results.html。对应测试见 tests/test_unit_test_db.py其中test_dump_to_report_cli_custom_args用monkeypatch替换sys.argv验证自定义路径下的报告生成test_dump_to_report_defaults验证默认路径行为test_dump_to_report则断言生成的 HTML 中确实包含插入的测试代码与测试文件内容。在集成测试中复用同一个数据库仓库的集成测试套件tests_integration也原生支持把同一个.db文件注入每个 Docker 容器。在仓库根目录执行LOG_DB_PATHfull_path_to_root_folder/run_tests.db tests_integration/test_all.sh其工作机制是tests_integration/test_all.sh 读取环境变量并转换为参数# Set the log_db_arg variable if LOG_DB_PATH is set log_db_arg if [ -n $LOG_DB_PATH ]; then log_db_arg--log-db-path $LOG_DB_PATH fi随后把$log_db_arg追加到 C、C、C#、Go、Java Gradle、Java Spring、VanillaJS、Python FastAPI、React、Ruby Sinatra、TypeScript 等全部 11 个场景的调用中。tests_integration/test_with_docker.sh 负责真正的容器编排先把宿主机上的数据库文件挂载进容器再在容器内以挂载点路径传给cover-agentif [ -n $LOG_DB_PATH ]; then LOG_DB_NAME$(basename $LOG_DB_PATH) ARGS$ARGS --volume $LOG_DB_PATH:/$LOG_DB_NAME fi ... if [ -n $LOG_DB_PATH ]; then COMMAND$COMMAND --log-db-path \/$LOG_DB_NAME\ fi这种「宿主机路径 → 容器内根目录同名文件」的映射方式取basename作为容器内路径使得来自不同语言、不同 Docker 镜像的多次运行结果最终都汇聚到同一个 SQLite 文件里方便跨项目对比各场景的生成质量。查询与观察测试数据运行完成后可以用外部数据库图形化工具或 SQLite 命令行客户端查看结果sqlite3 run_tests.db进入 sqlite3 后先列出所有表可以看到unit_test_generation_attempts已被创建sqlite .tables unit_test_generation_attempts查看表结构原文档输出的字段列表sqlite PRAGMA table_info(unit_test_generation_attempts); 0|id|INTEGER|1||1 1|run_time|DATETIME|0||0 2|status|VARCHAR|0||0 3|reason|TEXT|0||0 4|exit_code|INTEGER|0||0 5|stderr|TEXT|0||0 6|stdout|TEXT|0||0 7|test_code|TEXT|0||0 8|imports|TEXT|0||0提示如前所述当前版本的 SQLAlchemy 模型在 9 个基础列之外还包含language、prompt、source_file、original_test_file、processed_test_file等列实际PRAGMA table_info输出会比上表更长。常用查询示例-- 查看全部测试结果含格式化换行命令行下可能不易读GUI 更佳 select * from unit_test_generation_attempts; -- 只筛选失败的测试 select * from unit_test_generation_attempts where status FAIL;由于stdout、stderr、test_code等列包含多行文本与转义换行直接在终端里读select *会比较吃力实践中更推荐两类方式使用数据库 GUI 工具浏览宽表直接调用前文提到的报告导出能力生成 HTML 报告ReportGenerator会对状态着色PASS 绿 / FAIL 红并折叠展示完整 diff 与 stderr/stdout/test code/imports比裸 SQL 输出更易读。小结与适用前提该功能为 beta当前仅支持 SQLite 本地文件数据库连接串以sqlite:///前缀在源码中拼接长期目标是随 SQLAlchemy 扩展到其他数据库类型。启用方式--log-db-path命令行参数或LOG_DB_PATH环境变量环境变量优先默认值cover_agent_unit_test_runs.db来自 cover_agent/settings/configuration.toml。写入链路CoverAgent验证每轮生成的测试后通过 cover_agent/unit_test_db.py 的insert_attempt逐条落库运行结束时通过dump_to_report渲染 cover_agent/report_generator.py 的 HTML 报告。集成测试可通过LOG_DB_PATH... tests_integration/test_all.sh把单一数据库文件挂载进所有 Docker 场景实现跨项目数据汇聚。注意不要同时使用--suppress-log-files与--log-db-path在需要落库时因为源码中数据库的初始化与报告生成都以generate_log_files为前置条件。单测 tests/test_unit_test_db.py 覆盖了插入、查询、报告导出与 CLI 参数四条链路可作为理解该模块行为的最佳「活文档」。【免费下载链接】cover-agentQodo-Cover: An AI-Powered Tool for Automated Test Generation and Code Coverage Enhancement! 项目地址: https://gitcode.com/GitHub_Trending/co/cover-agent创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
