release readiness --verify-tests 对 Go 项目默认走 pytest，导致测试校验失真

[idoall]

问题描述

在 Go 项目中执行：

super-dev release readiness --verify-tests --json

工具会尝试调用 Python pytest 来做测试验证，而不是识别项目实际配置的 go test。这会导致 readiness 结果把 测试失败 归因到项目本身，即使项目的原生测试基线实际是通过的。

预期行为

对于 Go 项目：

• --verify-tests 应优先识别并执行 Go 原生测试命令，例如：

go test ./...

• 如果项目配置已声明：

  • backend: go
  • testing_frameworks: [go-test]

  则不应再退回到 pytest

• 如果当前版本尚不能识别，也至少应该：

  • 明确输出“未识别到当前语言对应测试命令”
  • 而不是错误地把 Python pytest 结果当作项目测试失败

实际行为

在 backend-only 的 Go 项目里，执行：

super-dev release readiness --verify-tests --json

曾得到类似错误：

/Users/.../python3: No module named pytest

结果表现为 readiness 中的 Test Suite 检查失败，但实际上项目的原生测试命令：

go test ./...

是可以正常通过的。

项目上下文

项目配置特征：

platform: api
frontend: none
backend: go
ui_library: none
style_solution: none
testing_frameworks:
  - go-test

项目真实测试基线：

go test ./...

影响

这会带来几个问题：

1. readiness 误报测试失败

   • 实际是工具调用了错误测试框架
   • 不是项目测试本身不通过

2. backend-only / Go 项目被错误降分

   • 尤其在 release closure 阶段会被误导成“测试未通过”

3. 用户难以判断是项目问题还是工具问题

   • 因为 --verify-tests 的语义本应是“验证项目测试”
   • 但实际变成了“尝试跑某个工具内部默认测试栈”

建议修复方向

建议支持以下至少一种：

1. 按语言 / backend 自动识别测试命令

   • backend: go -> go test ./...
   • backend: python -> pytest
   • backend: node -> 根据 package scripts / configured test runner 选择

2. 优先读取 testing_frameworks 配置

   • 如果配置为 go-test，则直接使用 Go 测试命令

3. 提供测试命令覆盖配置

   • 例如允许在配置中显式声明：

test_command: go test ./...

4. 在无法识别时优雅降级
   • 报告为“未识别测试命令”
   • 而不是默认回退到 pytest

附加说明

如果 --verify-tests 当前设计上就是偏向 Python / pytest，也建议在文档中明确说明适用范围，避免让 Go / backend-only 项目误用。

谢谢。

[shangyankeji]

感谢反馈，这个问题成立。
当前 super-dev release readiness --verify-tests在非 Python 项目上的测试命令识别还不完整，Go 项目会误落到 pytest路径，导致 readiness 把工具默认测试栈的失败误记成项目测试失败。这不符合预期。
这条我会按下面顺序修：

1. 优先读取显式 test_command
2. 其次读取 testing_frameworks
3. 再按 backend/ 项目类型自动选择原生测试命令
   go -> go test ./...
python -> pytest
node -> 优先 package scripts / runner
4. 如果仍无法识别，就明确返回“未识别测试命令”，不再默认回退到 pytest
   在修复落地前，Go / backend-only 项目先不要把 --verify-tests 的结果直接当成最终测试结论，先以项目原生测试命令为准，例如：
   go test ./...
   这条我先保留跟进