单元测试的好方法是使用另一个经过测试的功能来为实际测试做准备吗?

DIF*_*DIF 5 c# nunit unit-testing

我正在尝试使用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);
}
Run Code Online (Sandbox Code Playgroud)

k.m*_*k.m 8

在一个完美的世界中,每个单元测试只能以单一方式进行.每个单元测试都"孤立地"生活.你的addNewFruit测试可以通过打破来打破isInFruitsList- 但幸运的是,这也不是一个完美的世界.

既然你已经测试了isInFruitsList方法,你就不用担心了.这就像使用第三方API - 它(通常)经过测试,你认为它有效.在你的情况下,你假设isInFruitsList工作,因为,你 - 测试它.

绕过"以单一方式破坏"你可以尝试在内部公开底层水果列表(并使用InternalsVisibleTo属性),或通过依赖注入传递它.问题是 - 值得努力吗?你真正获得了什么?在这种简单的情况下,你通常会获得很少的东西,引入这些结构的开销通常是不值得的.

  • 绝对......如果测试的所有组合isInFruitsList都很好,并且它们是该代码的作者,那么它对于其他测试应该是可靠的......就像我们"依赖"C#和NUnit一样...... (2认同)
  • 那就对了.你总是需要在编写太少/太一般的测试和潜入测试`int a = 5`是否实际分配值之间找到平衡点.假设CLR,第三方代码和经过测试的代码工作总是更加明智,而不是偏执和测试所有移动的东西. (2认同)