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

Question

你会推荐什么策略来对现有的 Grails 应用程序进行单元测试？
我刚刚阅读了 Beck Kent 关于 TDD 的书，并希望将类似的方法应用于我的应用程序。
我的目标是对整个代码库进行单元测试，并能够重构代码并使其“更干净”。 “更干净”的意思是我想减少重复，通过将通用逻辑提取到服务中来使我的 Controller 更 slim ，等等。
那么我应该从哪里开始呢？楷模？ Controller ？
你做类似事情的“坏”和“好”经历是什么？

@彼得。
在我看来，我的应用程序并不太大。它由 12 个以上的模型、相似数量的 Controller 、很少的服务和大约 15 个 utils 类组成。
我希望拥有完整的单元测试覆盖率的主要原因之一是，在许多情况下系统可以正常工作。虽然从开发人员的角度来看，从用户的角度来看，这样的代码是一个改变和维护的噩梦。
另一件重要的事情是我想做小而快速的定期发布(新的小功能和/或改进)，但如果没有单元测试覆盖率，这几乎是不可能的。
所以问题不是:“我需要这样做吗？”，而是“ 我该怎么做？”

Answer 1

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

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

请注意，根据有关系统的可用文档和开发人员/用户知识水平，您可能无法始终确定特定功能的“正确”行为，只能确定其当前行为。即使在这种情况下，也值得用(单元)测试来覆盖它:这些测试记录了代码的实际行为，并在 future 检测到任何意外的变化。

一旦你有单元测试合理覆盖的实际代码段，这会给你重构所需的信心。每当您触摸代码时，都进行一些(简单或更复杂的)重构。但是，不要过度。如果您需要为错误修复更改一行，那么开始重构整个继承层次结构可能会有些过分(即使它真的很困惑)。记下此类即将发生的重构任务，并尝试稍后安排它们。