使用另一个经过测试的函数为实际测试做准备，这是一种很好的单元测试方法吗

本文关键字：测试 很好 测试方法 单元 一种 函数 经过 另一个 | 更新日期: 2023-09-27 18:21:40

我正在尝试使用NUnit进行单元测试。目前，我正在编写一个简单的测试，以习惯语法和单元测试的方式。但我不确定以下测试是否正确：

测试中的类包含一个包含水果名称的字符串列表，其中可以通过class_under_test.addNewFruit(...)添加新的水果名称。因此，为了测试addNewFruit(...)的功能，我首先使用该方法向列表中添加一个新字符串（例如"Pinapple"），然后在下一步中验证列表是否包含此新字符串。

我不确定这是否是测试方法功能的好方法，因为我依赖于另一个函数的响应（我已经在以前的单元测试中测试过了）。

这是测试这个功能的方法吗，还是有更好的解决方案？

public void addNewFruit_validNewFruitName_ReturnsFalse()
{
    //arrange
    string newFruit = "Pineapple";
    //act
    class_under_test.addNewFruit(newFruit);
    bool result = class_under_test.isInFruitList(newFruit);
    //assert
    Assert.That(!result);
}

使用另一个经过测试的函数为实际测试做准备，这是一种很好的单元测试方法吗

在一个完美的世界里，每个单元测试都只能用一种方式破坏。每个单元测试都与其他单元测试"隔离"。你的addNewFruit测试可以通过打破isInFruitsList来打破——但幸运的是，这也不是一个完美的世界。

由于您已经测试了isInFruitsList方法，所以不必担心。这就像使用第三方API一样-它（通常）经过测试，您认为它有效。在您的案例中，您假设isInFruitsList有效，因为您测试过它

绕过"breaked in a single way"，您可以尝试在内部公开底层水果列表（并使用InternalsVisibleTo属性），或者通过依赖项注入传递它。问题是——这值得付出努力吗？你真正的收获是什么？在这种简单的情况下，您通常获得的收益很少，并且引入此类构造的开销通常不值得花费时间。

相关文章：