单元测试 – 单元测试和重构现有Grails应用程序的策略
您建议对现有Grails应用程序进行单元测试的策略是什么?
我刚刚阅读了Beck Kent关于TDD的书,并希望对我的应用程序应用类似的方法. 我的目标是对整个代码库进行单元测试,并能够重构代码并使其“更清晰”. “更干净”是指我想减少重复,通过将常用逻辑提取到服务中来使我的控制器更加纤薄等等. 那么我应该从哪里开始呢?楷模?控制器? 做类似事情的“坏”和“好”经历是什么? @彼得. 解决方法
取决于应用程序的大小,但对于任何重要的现实生活应用程序来说,通过单元测试来满足地覆盖它是一项巨大的努力.因此,您需要优先考虑您的工作,专注于系统中最关键/最频繁更改/最多的错误部分(通常这些部分重叠很多:最关键的部分通常是最常触及添加新功能的部分或者修复错误).
一种好的方法是在需要触摸代码的任何部分时,或多或少地以TDD方式编写单元测试.我写的“或多或少”,因为对于遗留代码,您通常需要编写比绿地开发更高级别,更复杂的单元测试.事实上,在某些情况下,从单元测试开始甚至可能没有效率,相反,最好从用户的角度创建功能/系统测试以涵盖大粒度功能. 请注意,根据可用的文档和开发人员/用户对系统的了解程度,您可能无法始终确定特定功能的“正确”行为,只能确定其当前行为.即使在这种情况下,也值得用(单元)测试来覆盖它:这些文档记录了代码的实际行为,并在将来检测它中的任何意外变化. 一旦您获得了单元测试合理覆盖的实际代码,这将为您提供重构所需的信心.无论何时触摸代码,都要进行一些(简单或更复杂的)重构.但是,不要过分.如果你需要为一个错误修正改变一行,那么开始重构一个完整的继承层次结构(即使它真的很乱)可能有点过分了.记下这些即将发生的重构任务,并尝试稍后安排它们. (编辑:李大同) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |