这个Skill在解决什么问题
写完UI测试，你怎么确认它真的能抓到Bug？很多人的做法是：等CI跑完，看结果，祈祷。但这其实是在赌。verify-tests-fail-without-fix这个Skill专门解决这个问题——它会在你提交修复之前，先验证测试是否真的会因为Bug而失败，从而证明测试本身是有效的。
核心功能
这个Skill支持两种工作模式，覆盖了测试驱动开发的完整闭环。
- 仅验证失败模式（测试创建阶段）：适合先写测试、后写修复的场景。Skill会运行测试，确认它们在没有修复的情况下确实失败，证明测试逻辑是对的。
- 完整验证模式（修复验证阶段）：同时验证两件事——没有修复时测试失败，有修复后测试通过。这才是真正意义上的”测试有效性闭环”。
除了跑测试，它还会自动管理PR标签。验证通过打上绿色的s/ai-reproduction-confirmed，验证失败打上橙色的s/ai-reproduction-failed，PR状态一眼就清楚，不用再去翻日志。
输出文件也很完整，包括详细的验证报告、设备日志、NUnit测试输出，全部归档到CustomAgentLogsTmp/PRState/目录下，方便后续追溯。
适用平台
verify-tests-fail-without-fix作为一个标准化的AI Skill，可以无缝接入主流AI编程助手，成为它们的”测试质量守门员”。
- Cursor：在Cursor中调用这个Skill，AI在生成测试代码后可以立即触发验证，形成”生成-验证”的自动化循环。
- GitHub Copilot：配合Copilot的代码建议，验证AI生成的测试是否真的有效，而不是只是看起来像测试。
- Claude Code：Claude Code在处理复杂Bug修复时，可以用这个Skill来确认测试覆盖的准确性。
- OpenAI Codex / Gemini Code Assist：同样适用，任何能调用外部Skill的AI编程环境都能从中受益。
- 文心快码、腾讯云CodeBuddy、华为云CodeArts：国内主流AI编程平台同样可以集成，特别适合有.NET MAUI移动端项目的团队。
对于这些AI工具来说，verify-tests-fail-without-fix提供了它们自身缺乏的”测试有效性验证”能力，是真正意义上的上下文增强外挂。
实操代码示例
基础用法非常简单，一行命令搞定：
# 仅验证失败模式，自动检测测试过滤器
pwsh .github/skills/verify-tests-fail-without-fix/scripts/verify-tests-fail.ps1 -Platform android
# 完整验证模式，推荐加上 -RequireFullVerification 防止静默降级
pwsh .github/skills/verify-tests-fail-without-fix/scripts/verify-tests-fail.ps1 -Platform ios -TestFilter "Issue33356" -RequireFullVerification验证通过后，终端会输出这样的结果：
╔═══════════════════════════════════════════════════════════╗
║ VERIFICATION PASSED ✅ ║
╠═══════════════════════════════════════════════════════════╣
║ - FAIL without fix (as expected) ║
║ - PASS with fix (as expected) ║
╚═══════════════════════════════════════════════════════════╝看到这个输出，才算真正放心。
优势分析
市面上大多数测试工具关注的是”测试能不能跑通”，而verify-tests-fail-without-fix关注的是”测试有没有意义”。这是一个维度上的差异。
- 自动检测，零配置：Skill会从git diff中自动识别测试文件和修复文件，不需要手动指定，减少人为失误。
- 双向验证闭环：同时验证”有Bug时失败”和”修复后通过”，任何一个方向出问题都会被捕获。
- PR状态可视化：标签机制让团队所有人都能在PR列表页直接看到验证状态，不需要进入详情页查看日志。
- 防止静默降级：
-RequireFullVerification参数确保在没有检测到修复文件时直接报错，而不是悄悄切换到简化模式，避免误判。
应用场景
这个Skill最典型的使用场景是.NET MAUI移动端项目的Bug修复流程。
场景一：开发者收到一个UI Bug报告，先写UI测试复现问题，然后用verify-tests-fail-without-fix确认测试确实能抓到这个Bug，再开始写修复代码。这是标准的TDD流程，Skill在其中扮演”测试有效性验证”的角色。
场景二：团队在Code Review阶段，要求所有Bug修复PR必须附带通过完整验证的截图或报告。verify-tests-fail-without-fix生成的verification-report.md可以直接作为证明材料。
场景三：CI/CD流水线中，在合并前自动触发完整验证，确保没有”测试写了但抓不到Bug”的情况混入主分支。
最佳实践
在工程化落地时，有几个点值得注意。
首先，始终使用-RequireFullVerification。在修复阶段如果不加这个参数，脚本可能在没有检测到修复文件时静默降级，给你一个”看起来通过”的假结果。
其次，测试过滤器命名要有规律。Skill支持自动检测，但如果你的测试类命名不规范，自动检测可能失效。建议按Issue编号命名，比如Issue33356Tests，这样-TestFilter参数也能精准匹配。
第三，定期清理CustomAgentLogsTmp目录。每次验证都会生成日志文件，长期积累会占用不少空间，建议在CI环境中配置定期清理策略，或者只保留最近N次的记录。
第四，基础分支要保持同步。Skill依赖git diff来检测变更文件，如果本地基础分支和远端不同步，自动检测结果可能不准确。遇到这种情况，用-BaseBranch参数显式指定，或者先执行git fetch origin。
如果你的团队在维护多个.NET MAUI项目，或者有类似的跨平台移动端测试需求，把verify-tests-fail-without-fix这类Skill统一管理起来会更高效。Skill优仓提供了一个集中存放和分发这类工程化Skill的平台，团队成员可以直接从Skill优仓拉取使用，省去重复配置的麻烦。
暂无评论内容