【问题标题】:How to test method that wrapping another method?如何测试包装另一种方法的方法?
【发布时间】:2018-10-24 14:50:39
【问题描述】:

让我们想象有一个类(用类似 Java 的伪代码编写):

class MyClass {

    ...

    public List<Element> getElementsThatContains(String str) {
        return this.getElementsThatContains(new Set<String> { str });
    }

    public List<Element> getElementsThatContains(Set<String> strs) {

        ...

    }
}

首先 - 我有 getElementsThatContains(Set&lt;String&gt; strs) 正确 100% 覆盖。

我应该如何覆盖getElementsThatContains(String str)

  • 我是否应该复制(几乎)所有测试,但要调用getElementsThatContains(String str)
  • 我应该只做一个测试吗 检查第一种方法和第二种方法的结果是否相同的方法 (具有相同的传入数据)?
  • 我是否应该重构我的代码以使我没有 这样的情况? (如果是,怎么做?)

【问题讨论】:

  • 我只会为 getElementsThatContains(String str) 写,这也将涵盖下一次调用
  • @YogenRai,集合的输入有特定的逻辑。您建议通过调用方法#1 来测试所有“独立于设置”的登录,并通过调用方法#2 来测试所有“依赖于设置”的登录?我可以看到阅读我的代码的人会感到困惑。
  • 如果第二种方法有输入特定逻辑,那么您可以为两种输入场景编写..

标签: java unit-testing testing


【解决方案1】:

是的,您应该涵盖这两种方法。进行单元测试的原因是重构代码时的安全网。例如,有人可能会重构“getElementsThatContains(String str)”的实现,它总是会返回一个空列表。尽管 getElementsThatContains(Set strs) 具有 100% 的覆盖率,但这些测试无法捕捉到这一点。

不,您不应该使用一种测试方法来检查第一种方法和第二种方法的结果是否相同。这通常被认为是一种不好的做法。此外,如果一种方法存在错误,您的测试只会检查另一种方法是否返回相同的错误结果。

不,您不应该复制所有测试,因为每种方法的测试用例会有所不同。方法的论据是不同的。因此,尽管调用了相同的方法,但每个测试用例都会有不同的测试用例。

【讨论】:

    【解决方案2】:

    是的,您应该测试这两种方法,并且应该为每种方法使用不同的测试用例。

    但您应该较少关心您的线路覆盖率
    不要在这里误会我的意思!保持高线路覆盖率很重要。但更重要的是拥有 100% 的行为覆盖率。如果您遇到未经测试的行,您的问题应该是:“这个未经测试的代码是需要的(即它实现了什么要求)还是已经过时了?”

    在编写测试时考虑到行覆盖率,我们倾向于关注被测代码的实现细节。因此,当我们更改此实现细节(例如,在重构期间)时,我们的测试可能会失败。但是我们的测试应该只在被测试的行为改变而不是当我们改变实现这种行为的方式时才会失败。

    【讨论】:

      猜你喜欢
      • 2016-12-30
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2023-03-12
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多