Как настроить внутреннее состояние структуры данных во время модульного тестирования? - PullRequest
12 голосов
/ 16 октября 2008

Я пишу структуру данных в C # (приоритетная очередь, использующая кучу fibonacci ), и я пытаюсь использовать ее в качестве учебного процесса для TDD, для которого я довольно новичок.

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

Например,

private PriorityQueue<int> queue;

[SetUp]
public void Initialize()
{
    this.queue = new PriorityQueue<int>();       
}

[Test]
public void PeekShouldReturnMinimumItem()
{
    this.queue.Enqueue(2);
    this.queue.Enqueue(1);

    Assert.That(this.queue.Peek(), Is.EqualTo(1));
}

Этот тест прервется, если сломается либо Enqueue, либо Peek.

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

Есть ли лучший способ сделать это? Можно ли полагаться на другие части?

У меня есть SetUp на месте, просто упустил его для простоты.

Ответы [ 3 ]

7 голосов
/ 16 октября 2008

Добавьте приватный аксессор для класса в ваш тестовый проект. Используйте средство доступа для установки частных свойств класса некоторым известным способом вместо использования методов классов для этого.

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

3 голосов
/ 16 октября 2008

Теоретически, вы хотите протестировать только одну функцию за раз. Однако, если ваша очередь имеет только несколько методов (Enqueue, Peek, Dequeue, Count), то вы весьма ограничены в видах тестов, которые вы можете выполнять, используя только один метод.

Лучше не переусердствовать в решении проблемы, а просто создать несколько простых тестовых случаев (например, приведенных выше) и использовать их для обеспечения надлежащего охвата различных функций.

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

1 голос
/ 16 октября 2008

Я думаю, что это нормально, но очистите очередь в начале вашего метода тестирования.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...