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

Question

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

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

Answer 1

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

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

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

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

Answer 2

我普遍同意@Peter的说法，这是一件非常重要的事情，你可能会因为知道什么事情而不是他们想要做什么而受到阻碍。但这没关系，如果不是理想的话，因为测试与可维护性（即知道更改何时破坏事物）同样重要，因为它与正确性有关。因此，现在就对现有功能进行测试，如果必须修复错误，可以更改测试以捕获修复。

如果您和您的团队专注于添加新功能，那么现在就实施TDD，即测试新功能，并添加您正在修改的现有功能的测试，如已经建议的那样。

如果你可以专注于测试，那么我会在垂直层测试。为模型编写一些测试，然后是服务，然后是控制器（这个命令只是一个建议）。关键是，如果您正在测试应用的“预订”部分，请在继续之前测试所有预订功能。此外，您可以优先考虑应用程序的核心功能。如果“书籍”比其他东西重要得多，那么首先测试“书籍”。

Answer 3

就个人而言，我发现最容易进行Grails集成测试。仅针对一些常用的bean，我进行了单元测试。我承认这不是TDD，但仍然给你一些信心。