【问题标题】:How to retroactively add tests to a code base?如何追溯地将测试添加到代码库中?
【发布时间】:2014-05-12 20:03:19
【问题描述】:

假设您的任务是向单元测试覆盖率非常低的现有代码库添加测试框架。代码库还不是特别大,但是,它确实有一些地方不是很干净,或者不是非常 OOP 或可测试的。

我已经阅读了几个很好的答案:

但我正在进行的项目是一个 Android 应用程序,所以它略有不同(考虑到更多的 UI 组件)。

我有一些与同一问题有关的问题:

  1. 返回并进行大量测试的最佳方法是什么?
  2. 如何确定首先测试哪些部件的优先级?
    • 我是否从经常调用它的区域开始(并且有这样的代码分析工具)?
    • 或者我应该回去看看过去有最多错误数量的类吗?
  3. 我是否应该先编写集成测试(鉴于这是一个 Android 应用,而且集成测试可能会防止损坏的单元测试/重构)然后在单元测试中工作?

抱歉所有问题,只是真的在寻找一种好的方法,更具体地说是针对回顾性测试 Android 应用程序。

附:我很好奇人们是否知道他们可以用于代码分析的好工具,这些工具可以帮助关注代码库中单元测试最有帮助的领域。

【问题讨论】:

    标签: android unit-testing testing refactoring integration-testing


    【解决方案1】:

    通常在开始对现有应用程序进行单元测试时,您会希望迭代地进行 - 您可能没有时间或人力来进行大量的前期投资,因此您希望将单元测试作为必需的一部分添加工作:

    1. 在添加新功能时编写 unt 测试 - 或者更好的是使用 TDD
    2. 修复错误时 - 在修复错误之前编写单元测试失败的错误
    3. 重构旧代码时编写单元测试以确保没有引入回归总线

    如果整个团队在几周内完成上述三个步骤,您应该可以很好地覆盖您一直在更改的代码 - 取决于项目的大小。

    【讨论】:

      【解决方案2】:

      我没有针对 Android 的答案。我希望有人出现并添加一个好的。同时:为您最重要的功能编写验收(集成)测试(从产品所有者的角度,而不是从某些工具的角度)。您将获得最大的覆盖面,并最有可能防止客户关心的错误。不要太担心单元测试;这些是为了详细说明。

      [这是你引用的第三篇文章中给出的答案,但我们仍在等待那个精通 Android 的答案,所以我们暂时不要称之为重复。]

      编写验收测试,并在必要时为新功能编写单元测试,并在修复错误时编写单元测试。

      关于如何找到需要测试的代码区域,首先要做的是测量代码覆盖率。 (You can do that in the Android SDK with ant emma debug install test.) 显然没有覆盖的代码需要测试。

      【讨论】:

        猜你喜欢
        • 1970-01-01
        • 1970-01-01
        • 2019-09-29
        • 2016-11-10
        • 2011-12-11
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 2022-12-08
        相关资源
        最近更新 更多