Код модульного тестирования, который в основном делает персистентность.

Question

Я использую API, который взаимодействует с БД. Этот API имеет методы для запроса, загрузки и сохранения элементов в БД. Я написал интеграционные тесты, которые делают такие вещи, как создание нового экземпляра, а затем проверяют, что когда я делаю запрос для этого экземпляра, правильный экземпляр найден. Это все хорошо.

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

public class ElementSaver
{
    private ITheApi m_api;

    public bool SaveElement(IElement newElement, IElement linkedElement)
    {
        IntPtr elemPtr = m_api.CreateNewElement()
        if (elemPtr==IntPtr.Zero)
        {
            return false;
        }
        if (m_api.SetElementAttribute(elemPtr,newElement.AttributeName,newElement.AttributeValue)==false)
        {
             return false;
        }
        if (m_api.SaveElement(elemPtr)==false)
        {
             return false;
        }

        IntPtr linkedElemPtr = m_api.GetElementById(linkedElement.Id)
        if (linkedElemPtr==IntPtr.Zero)
        {
            return false; 
        }
        if (m_api.LinkElements(elemPtr,linkedElemPtr)==false)
        {
            return false;
        }
        return true;

    }
}  

стоит ли писать модульные тесты, которые макетируют член m_api? кажется, что я могу проверить, что если какой-либо из различных вызовов потерпит неудачу, возвращается false, и что, если все различные вызовы завершатся успешно, будет возвращено значение true, и я мог бы установить ожидания, что различные методы вызываются с ожидаемыми параметрами, но это полезно? Если бы я реорганизовал этот код так, чтобы он использовал несколько другие методы API, но достиг того же результата, это сломало бы мои тесты, и мне нужно было бы их изменить. Эта хрупкость не кажется очень полезной.

Стоит ли беспокоиться о модульных тестах для подобного кода или просто придерживаться имеющихся интеграционных тестов?

Answer 1

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

Answer 2

Хорошей идеей будет макетирование m_api в моем коде по следующим причинам (не все из которых применимы к вашему примеру с псевдо-кодом):

• Как вы упомянули, вы можете убедиться, что ваш класс выполняет обработку ошибок правильно
• В тех случаях, когда у вас есть более сложный код в вашем классе (например, кеширование), вы можете использовать ожидания на макете, чтобы убедиться, что класс ведет себя правильно. Например, получите один и тот же объект дважды, но убедитесь, что m_api вызывается только один раз.
• Ваш модульный тест может проверить поведение без создания соответствующего набора данных. Это повышает удобство сопровождения с течением времени по мере изменения модели данных под m_api.