单元测试 – 单元测试和重构现有Grails应用程序的策略

您建议对现有Grails应用程序进行单元测试的策略是什么？
我刚刚阅读了Beck Kent关于TDD的书,并希望对我的应用程序应用类似的方法.
我的目标是对整个代码库进行单元测试,并能够重构代码并使其“更清晰”. “更干净”是指我想减少重复,通过将常用逻辑提取到服务中来使我的控制器更加纤薄等等.
那么我应该从哪里开始呢？楷模？控制器？
做类似事情的“坏”和“好”经历是什么？

@彼得.
在我看来,我的应用并不算太大.它由12个模型,相似数量的控制器,少量服务和大约15个utils类组成.
我希望获得完整的单元测试覆盖率的主要原因之一是,在许多情况下系统才能正常工作.从开发人员的角度来看,从用户的角度来看,这样的代码是改变和维护的噩梦.
另一个重要的事情是我希望制作小而快速的常规版本(新的小功能和/或改进),但如果没有单元测试覆盖率,它几乎是不可能的.
所以问题不是：“我需要这样做吗？”,但“我怎么能这样做？”

取决于应用程序的大小,但对于任何重要的现实生活应用程序来说,通过单元测试来满足地覆盖它是一项巨大的努力.因此,您需要优先考虑您的工作,专注于系统中最关键/最频繁更改/最多的错误部分(通常这些部分重叠很多：最关键的部分通常是最常触及添加新功能的部分或者修复错误).

一种好的方法是在需要触摸代码的任何部分时,或多或少地以TDD方式编写单元测试.我写的“或多或少”,因为对于遗留代码,您通常需要编写比绿地开发更高级别,更复杂的单元测试.事实上,在某些情况下,从单元测试开始甚至可能没有效率,相反,最好从用户的角度创建功能/系统测试以涵盖大粒度功能.

请注意,根据可用的文档和开发人员/用户对系统的了解程度,您可能无法始终确定特定功能的“正确”行为,只能确定其当前行为.即使在这种情况下,也值得用(单元)测试来覆盖它：这些文档记录了代码的实际行为,并在将来检测它中的任何意外变化.

一旦您获得了单元测试合理覆盖的实际代码,这将为您提供重构所需的信心.无论何时触摸代码,都要进行一些(简单或更复杂的)重构.但是,不要过分.如果你需要为一个错误修正改变一行,那么开始重构一个完整的继承层次结构(即使它真的很乱)可能有点过分了.记下这些即将发生的重构任务,并尝试稍后安排它们.