Модульное тестирование Добавить / Получить пары методов

Question

Я разработчик .Net-кода на C #, и мне поручили проект, который его менеджер хочет, чтобы он был полностью модульным, в основном подчеркивая изоляцию, так что одна логическая ошибка в идеале не проходит один тест, и нет никаких зависимостеймежду тестами.

Сегодня мы обсуждаем шаблоны тестирования, и возник следующий вопрос:

Допустим, у нас есть объект с именем MyHashTable, который реализует:

void Add(string key, string value);

string GetValue(string key);

Мыхочу проверить каждый из этих методов независимо .Конечно, главная проблема в том, что логически мы не можем получить то, что никогда не добавляли, и мы не можем проверить, что что-то было добавлено, не получив этого.Мы слышали и читали о заглушке / насмешках и других методах, которые могут помочь преодолеть эти проблемы, но не можем решить, какое решение будет наиболее читабельным и пригодным для использования.

Поэтому я прошу совета / идеи, как протестировать эти методы в отдельности, и, если вы можете, включить плюсы и минусы для вашего предложения.Спасибо!

Answer 1

Если вы хотите достичь полной независимости и изоляции , то вам, скорее всего, придется раскрыть некоторые внутренние элементы MyHashTable.Например, базовая коллекция, в которую Add добавляет элементы:

public class MyHashTable<TKey, TValue>
{
    internal Dictionary<TKey, TValue> Storage { get; set; }
    // ...
}

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

Редактировать:

Обратите внимание, что я не предлагаю раскрывать внутренние детали / детали реализации в качестве единственного пути для подражания.Вы можете просто протестировать эти методы вместе (не как в одном тесте, а один, использующий другой), что может оказаться лучшим решением.Конечно, если ваш Add в какой-то момент не пройдёт, тесты Get тоже не пройдут.Но опять же, вы хотите исправить сломанный Add - как только это будет сделано, все вернется к норме.Естественно, проблема заключается в том, как вы различаете, был ли сломан Add или Get, но именно здесь пригодятся сообщения о сбое правильного утверждения или концепция защитных утверждений, которые я связал в комментарии.

Правда в том, что иногда полное разделение и изоляция слишком трудны для достижения, или вам просто нужно ввести плохой дизайн.Это одна из причин, по которой они никогда не должны быть конечной целью.

Answer 2

Почему? Цель модульного теста - убедиться, что тестируемый метод работает так, как ожидалось. Ничто не говорит о том, что вы не можете использовать другие методы, чтобы убедиться, что протестированный метод работает нормально.

следующие тесты мне подходят (для реализации с хеш-таблицей)

[Fact]
public void AddNewItem()
{
    var hashTable = new MyHashTable();

    hashTable.Add("hello", "world");

    Assert.True(hashTable.Exists("hello"));
    Assert.Equal("world", hashTable["hello"]);
}

[Fact]
public void AddExistingItem()
{
   var hashTable = new MyHashTable();

   hashTable.Add("hello", "world");
   hashTable.Add("hello", "realItem");

   Assert.Equal("realItem", hashTable["hello"]);
}

Конечно, вы можете разбить внутреннее хранилище на интерфейс и вставить его в конструктор:

public class MyHashTable
(
    public MyHashTable(IKeyValueStorage storage)
    {}

    // creates a default storage class
    public MyHashTable()
    {}
)

Что позволяет вам макетировать хранилище и, следовательно, тестировать один метод за раз. Но это только продвигает проблему на один шаг вперед. как вы собираетесь протестировать реализацию хранилища?

То, что я говорю, это то, что HashTable - это маленькая изолированная единица. Это хорошо, чтобы проверить это, используя его методы. У вас не будет этой проблемы с моделями доменов, так как вы можете высмеивать их зависимости.