Как проверить значение переменной, которая существует только внутри этой функции?

Question

Я пытаюсь реализовать некоторые модульные тесты для функции, но один из входных данных не меняет того, что возвращает функция. Хотя этот ввод не изменит то, что возвращает функция, он мне все еще нужен для API внутри кода. Функция выглядит примерно так:

    public bool IsEmailSent(string userEmail, bool isJson)

    {

        var link = isJson ? "Link1" : "Link2";

        if (string.IsNullOrEmpty(userEmail))
        {
            return false;
        }

        //Some other code

        return true;
    }

То, что я пытаюсь сделать, это проверить значение переменной 'link', которое зависит от ввода 'isJson'. Итак, тест, который я хотел реализовать, выглядит примерно так:

     [TestMethod]
     public void link_should_be_link2_when_isJson_is_false()
     {
            //if isJson is false && link = link2, test is sucessful
     }

Проблема в том, что я понятия не имею, как получить переменную 'link' внутри теста, чтобы проверить правильность ее значения, поскольку моя функция не возвращает его. Итак, как мне проверить значение переменной некоторой функции, которая зависит от заданного входа, но моя функция не возвращает ничего, близкого к значению этой переменной?

Answer 1

При выполнении модульного тестирования рассмотрите функцию, подобную черному ящику. Тестируйте комбинации входов, тестируйте идемпотентность и т. Д. Реализация действительной функции может быть абстрагирована от модульных тестов. Не видя

//Some other code

Я бы посмотрел, можно ли превратить вызов API в вспомогательную функцию. Затем напишите отдельные модульные тесты для вспомогательной функции.

Answer 2

Поскольку вычисление link в вашей функции не влияет на возвращаемое значение, оно будет иметь какой-то другой наблюдаемый эффект, потому что в противном случае вычисления не потребуются.В вашем случае кажется вероятным, что эффект будет заметен в том, как ваша функция link обращается к зависимому компоненту (DOC), возможно, к какой-то функции, которая отправляет электронное письмо.

У вас есть множествоздесь можно указать:

• Вы можете макетировать вызов функции DOC, которая отправляет электронное письмо, чтобы узнать, вызывается ли оно, как ожидается, для ожидаемого промежуточного значения link.
• Вы можете выделить некоторые вспомогательные функции из link, как было предложено elgonzo.
• Вы можете рассмотреть возможность рефакторинга своего кода, чтобы избежать аргумента логического элемента управления, который выглядит как запах кода , например, чтобы иметь разные функции для случая Json и не-Json.Тем не менее, проблема тестирования должна быть решена в соответствии с выбранным вами новым дизайном.
• ...

Однако некоторые замечания: Юнит-тестирование - это не черный ящиктехника.Фактически, некоторые из методик разработки тестов, специфичных для модульного тестирования, имеют смысл только для тестирования стеклянного ящика (или белого ящика), а именно всех методов проектирования тестирования на основе покрытия.Попытка сохранить весь комплект модульных тестов независимым от деталей реализации может привести к неэффективному комплекту тестов, то есть к комплекту тестов, который не подходит для поиска всех найденных ошибок.

Ошибкив конце концов, в реализации.Разные реализации будут иметь разные ошибки.Подумайте о различных способах реализации функции Фибоначчи: как итеративной / рекурсивной функции, выражения закрытой формы (Moivre / Binet), справочной таблицы: каждая реализация имеет разные потенциальные ошибки.Модульное тестирование - это метод тестирования в нижней части тестовой пирамиды , и все высокоуровневые тесты (интеграционные или системные тесты) менее подходят для поиска ошибок в деталях реализации.И поиск ошибок - одна из основных целей тестирования (см. Майерс, Бадгетт, Сандлер: Искусство тестирования программного обеспечения или Бейзер: методы тестирования программного обеспечения и многие другие).

Поэтому наилучший подход состоит в том, чтобыкак можно больше полезных тестов, которые не зависят от реализации.Кроме того, вам, вероятно, потребуются дополнительные тесты, которые направлены на поиск потенциальных ошибок в выбранной реализации.Однако чем менее стабилен аспект реализации, тем больше вам следует избегать зависимости тестов от нее: вспомогательные функции с большей вероятностью могут быть переименованы, объединены или удалены, чем функции, формирующие официальный API вашего компонента.