它是单元测试的一个好办法，用另一个测试功能，使preparations进行实际测试？ [英] Is it a good way of unit testing to use another, tested function to make preparations for the actual test?

问题描述

我试图让与NUnit的单元测试。目前，我正在写一个简单的测试，习惯的语法和单元测试的方式。但我不知道如果我这样做是正确的以下测试：

被测类持有含有水果的名称，在新的水果名称可以通过添加class_under_test.addNewFruit（...）的字符串列表。因此，要测试 addNewFruit的功能（...），我第一次使用的方法一个新的字符串添加到列表（例如菠萝），并在下一步，验证是否列表包含这个新的字符串。

我不知道这是否是测试方法的功能的好方法，因为我靠另一个函数（我已经在previous单元测试已经测试）的响应。

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

 公共无效addNewFruit_validNewFruitName_ReturnsFalse（）
{
    //安排
    字符串newFruit =菠萝    //法案
    class_under_test.addNewFruit（newFruit）;
    布尔结果= class_under_test.isInFruitList（newFruit）;    //断言
    Assert.That（！结果）;
}
 

解决方案

在一个完美的世界，每一个单元测试只能在单一的方式打破。每个单元测试住在隔离所有其他。你的 addNewFruit 测试可以打破被打破 isInFruitsList - 但幸运的是，这不是一个完美的世界要么

既然你已经测试了 isInFruitsList 方法，你不应该担心。这就像使用第三方API - 它（的一般的）进行测试，和你认为它的作品。在你的情况，你认为 isInFruitsList 工作，因为，好 - 你测试了它

绕来绕去的在一个单一的方式打破的你可以尝试揭露内部潜在的水果列表（并使用<一个href=\"http://msdn.microsoft.com/en-us/library/system.runtime.compilerservices.internalsvisibletoattribute.aspx\"><$c$c>InternalsVisibleTo属性），或通过依赖注入传递给它。问题是 - 它是值得的？你到底得到什么？在这种情况下，简单，通常获得非常少的，引入这种结构的开销通常是不值得的时间。

I'm trying to get into unit testing with NUnit. At the moment, I'm writing a simple test to get used to the syntax and the way of unit testing. But I'm not sure if I'm doing it right with the following test:

The class under test holds a list of strings containing fruit names, where new fruit names can be added via class_under_test.addNewFruit(...). So, to test the functionality of addNewFruit(...), I first use the method to add a new string to the list (e.g. "Pinapple") and, in the next step, verify if the list contains this new string.

I'm not sure if this is a good way to test the functionality of the method, because I rely on the response of another function (which I have already tested in a previous unit test).

Is this the way to test this function, or are there better solutions?

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);
}

解决方案

In a perfect world, every unit test can only be broken in single way. Every unit test "lives" in isolation to every other. Your addNewFruit test can be broken by breaking isInFruitsList - but luckily, this isn't a perfect world either.

Since you already tested isInFruitsList method, you shouldn't worry about that. That's like using 3rd party API - it (usually) is tested, and you assume it works. In your case, you assume isInFruitsList works because, well - you tested it.

Going around the "broken in a single way" you could try to expose underlying fruits list internally (and use InternalsVisibleTo attribute), or passing it via dependency injection. Question is - is it worth the effort? What do you really gain? In such simple case, you usually gain very little and overhead of introducing such constructs usually is not worth the time.

这篇关于它是单元测试的一个好办法，用另一个测试功能，使preparations进行实际测试？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！