Является ли хорошим способом модульного тестирования использовать другую, проверенную функцию для подготовки к настоящему тесту?

Question

Я пытаюсь начать модульное тестирование с помощью 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);
}

Answer 1

В идеальном мире каждый юнит-тест может быть сломан только одним способом. Каждый юнит-тест «живет» изолированно друг от друга. Ваш addNewFruit тест может быть нарушен, если вы нарушите isInFruitsList - но, к счастью, этот мир тоже не идеален.

Поскольку вы уже протестировали метод isInFruitsList, вам не стоит об этом беспокоиться. Это похоже на использование стороннего API - оно ( обычно ) проверяется, и вы предполагаете, что оно работает . В вашем случае вы предполагаете, что isInFruitsList работает, потому что, ну - вы это проверили.

Обойдя «сломанный в одиночку» , вы можете попытаться раскрыть основной список фруктов внутри себя (и использовать атрибут InternalsVisibleTo) или передать его через внедрение зависимостей. Вопрос - стоит ли усилий? Что вы на самом деле получаете? В таком простом случае вы обычно получаете очень мало, и затраты на внедрение таких конструкций обычно не стоят времени.