我做TDD,我在组织单元测试时相当松散.我倾向于从表示下一个故事或功能块的文件开始,并编写所有单元测试以使其工作.
当然,如果我正在引入一个新类,我通常会为该类创建一个单独的单元测试模块或文件,但我不会将测试本身组织到任何更高级别的结构中.结果是我快速编写代码并且我相信我的实际程序结构合理,但单元测试本身是"混乱的".特别是,它们的结构倾向于概括开发过程的系统发育.有时我认为自己在测试中懒惰的代码中交易懒惰.
这有多大的问题?谁在这里不断重构和重组他们的单元测试以试图改善他们的整体结构?有什么提示吗?测试的整体结构应该是什么样的.
(注意,我不是在问这个问题"每个函数有多少个断言"问题:我应该为每个函数/方法编写多少个单元测试?我在谈论更大的图片.)
将您的测试分为两组:
功能测试
单元测试
功能测试是每个用户的故事.单元测试是按班级进行的.前者检查您是否真正支持故事,后者练习并记录您的功能.
有一个目录(包)用于功能测试.单元测试应该与他们运用的功能密切相关(因此它们是分散的).当你移动和重构你的代码时,你移动它们并重构它们.