提前以注释形式规划测试用例，是否仍属于TDD范畴？

结论先行：这属于TDD的前置规划环节，只要后续跟进标准的红-绿-重构循环，就完全符合TDD的核心要求。

先明确标准TDD的核心逻辑 #

TDD的本质是「先定义行为，再实现功能」，核心循环是：

• 红：编写一个会失败的可执行测试（对应功能尚未实现）
• 绿：编写最少的代码让测试通过
• 重构：优化代码和测试的结构，不改变功能

你的做法为什么符合TDD的核心思想 #

你用注释列出所有测试用例名称的行为，是在把需求拆解成可验证的最小行为单元——比如guest_can_register_with_valid_data、guest_can_register_with_valid_data_and_receive_verification_sms，这些注释其实就是在明确：系统必须满足哪些场景下的行为要求。这完全契合TDD「先明确“要做什么”，再写“怎么做”」的核心原则。

很多资深TDD开发者都会先做这一步：先梳理出所有需要覆盖的测试场景，避免后续开发中遗漏需求，让红-绿循环的目标更清晰。

关键的区分点 #

如果只是停留在列注释，不把这些注释转换成可执行的测试代码，也不进入红-绿-重构循环，那只能算「测试规划」，不能算完整的TDD。但如果以此为起点，逐个将注释替换成可运行的测试（先让测试失败），再写代码让测试通过，最后重构优化，那就是标准的TDD流程。

举个你的示例的后续流程 #

比如针对guest_can_register_with_valid_data：

1. 把注释改成可执行的测试方法，运行后测试失败（红）
2. 编写用户注册的核心代码，让测试通过（绿）
3. 优化注册代码的结构（比如提取重复逻辑、规范命名），确保测试依然通过（重构）
4. 再处理下一个注释的测试用例，重复循环

内容的提问来源于stack exchange，提问作者Skeletor