springboot-tdd
作者 affaan-mspringboot-tdd 是一个面向 Spring Boot 的测试先行工作流技能，结合 JUnit 5、Mockito、MockMvc、Testcontainers 和 JaCoCo。可用于新增功能、修复缺陷或重构，同时保持清晰的测试意图和较高覆盖率。特别适合用于测试自动化和后端变更的 springboot-tdd。
该技能得分为 74/100，说明它是一个适合想要聚焦 Spring Boot TDD 工作流的用户的目录条目。仓库提供了足够具体的指导，可用于触发并应用该技能，而不必靠猜测；但它更像一份结构化作战手册，而不是已经完全产品化、可直接安装的技能，因此使用时仍需预期一些落地上的注意事项。
- 触发条件和使用场景很清楚：明确提到了“新功能或端点”、“缺陷修复或重构”，以及“加入数据访问逻辑或安全规则”。
- 工作流足够具体：先写测试，再实现最小代码，然后重构，最后用 JaCoCo 强制覆盖率。
- 提供了可执行的 JUnit 5/Mockito 和 MockMvc 示例，相比泛泛的提示词，更利于智能体直接上手。
- 没有提供安装命令、脚本或配套支持文件，因此只能依赖 SKILL.md 中的说明进行使用。
- 带有实验性/测试性质的信号，而且缺少参考资料或资源，可信度和完整性只能算中等，而不是很强。
springboot-tdd 技能概览
springboot-tdd 是一个专注于 Spring Boot 测试先行工作流的技能，用于借助 JUnit 5、Mockito、MockMvc、Testcontainers 和 JaCoCo 来构建或修改后端代码。它最适合需要一种可重复的方法来添加功能、修复缺陷或重构代码，同时保持较高覆盖率和清晰测试意图的开发者与 agent。
springboot-tdd 的用途
springboot-tdd 技能帮助你把“加一个 endpoint”或“修一下 service 的 bug”这类需求，转成一套测试先行的实现计划。它真正的作用，是把 TDD 流程说清楚：先写一个会失败的测试，再做最小改动实现，最后安全地重构。
适用场景与不适用场景
springboot-tdd 适用于 service 逻辑、controller 行为、持久化规则以及 security 检查等回归风险较高的场景。对于前端工作、临时排障，或者不需要测试先行步骤的大型架构重设计，它的匹配度就比较弱。
为什么这个技能不一样
和通用提示词相比，springboot-tdd 提供了更贴合 Spring Boot 的测试栈，以及更清晰的决策路径，帮助你判断该用单元测试、web 层测试还是集成测试。它的核心价值，是减少“先测什么”以及“如何让实现始终和测试保持一致”上的猜测。
如何使用 springboot-tdd 技能
安装 springboot-tdd 技能
使用目录安装器把该技能加入你的 Claude Code 环境：
npx skills add affaan-m/everything-claude-code --skill springboot-tdd
这就是 springboot-tdd 的安装步骤；安装完成后，当你的任务需要在 Spring Boot 仓库里做测试驱动修改时，就可以使用这个技能。
先阅读正确的文件
先看 SKILL.md 了解核心工作流，然后再检查仓库里存在的关联项目文档或辅助文件。对于这个技能来说，最值得先看的通常是工作流部分和测试示例，因为它们会展示预期的测试风格，以及单元测试和 web 层测试之间的边界。
给技能一个明确的测试目标
springboot-tdd 的使用效果最好时，前提是你提供了具体的代码路径和期望行为。好的输入例如：
- “新增一个
createMarketservice 方法，拒绝空白名称并持久化合法请求。” - “为
GET /api/markets写一个 controller 测试，返回空页面和 200 响应。” - “在不改变当前行为的前提下重构这个 repository 查询。”
像“改进测试”或“让它更健壮”这类模糊输入，会迫使技能去猜验收标准。
按 TDD 流程顺序执行
用这个技能先规划测试，再写代码，最后做重构。一个实用的 springboot-tdd 指南通常会产出：
- 一个失败的单元测试或 web 层测试，
- 满足该测试的最小实现，
- 测试通过后的清理重构，
- 用 JaCoCo 做覆盖率检查。
如果改动会跨层，应该把测试选择拆开，而不是把所有内容硬塞进同一种测试里。
springboot-tdd 技能常见问题
springboot-tdd 只适合从零开始的新项目吗？
不是。springboot-tdd 技能对现有的 Spring Boot 服务尤其有用，因为 bug 修复和重构在改代码前就更需要回归测试。它同样适用于新代码，但并不局限于新项目。
它和普通提示词相比有什么不同？
普通提示词也能描述 TDD，但 springboot-tdd 会提供一套可复用的 Spring Boot 测试选择工作流，包括什么时候用 Mockito、MockMvc，以及如何落实覆盖率约束。这通常意味着更少来回沟通，也更少出现空泛的测试建议。
对初学者友好吗？
如果你已经能读懂基础的 Java 测试，那它是友好的。这个技能对 Spring Boot 团队来说上手门槛不高，因为它给出的是一条可执行的实践路径，但使用者仍然需要提供清晰的行为目标，并理解自己项目的测试结构。
适合 Test Automation 吗？
适合。对于以可靠后端验证为目标的 Test Automation，springboot-tdd 是一个不错的选择。它更适合做后端校验，而不是 UI 脚本。如果你需要浏览器自动化、Spring Boot 之外的契约工具，或者非 Java 的测试栈，它就不那么合适了。
如何改进 springboot-tdd 技能
在要代码之前先把行为说清楚
springboot-tdd 的最佳结果来自精确的验收标准：输入、输出、边界情况和失败条件。不要只说“给 orders 加测试”，而要说“拒绝重复的 order ID，冲突时返回 409，并保持服务幂等”。
选对测试层级
常见问题之一，是本来单元测试更快更清楚，却去要集成测试；或者反过来。想让 springboot-tdd 的输出更好，就要明确说明这次改动涉及纯业务逻辑、HTTP 行为、数据库访问，还是外部依赖。
提供会影响实现的约束
把 framework 版本、数据库配置、security filters，以及任何和 Testcontainers 或 CI 有关的限制都说出来。这些信息能帮助 springboot-tdd 指南避免脆弱假设，生成真正贴合你项目的测试，而不是教科书式样例。
从失败测试迭代到最终形态
如果第一次输出范围太大，就要求它缩小到更细的测试切片，等第一个测试通过后再扩展。最快的改进路径通常是：一个场景、一个 test class、一次行为变更，然后再做第二轮，补边界情况和覆盖率缺口。