Как бы перевести это на модульный тест?

Question

Большинство примеров, которые я вижу в модульных тестах, - это простые тесты, такие как Assert.That (5, 2 + 3), но как я могу включить модульный тест в метод, который получает информацию о пользователях и сохраняет их в базе данных. Например, у меня есть метод Register, который принимает объект User. Свойства объекта пользователя заполняются из веб-формы, а затем сохраняются в базе данных. Каковы некоторые жизнеспособные модульные тесты, которые я мог бы сделать с этим?

Вот пример. Предположим, что объект User имеет некоторые обязательные поля, такие как Email, FirstName, LastName. Если бы действительный модульный тест утверждал, что электронная почта не является нулевой или пустой. То же самое относится к другим обязательным полям. Таким образом, в моем сценарии выше, будет ли это единичным тестом.

[Test] 
public void EmptyEmailShouldReturnError() 
{ 
    User user = new User(); 
    user.Email = ""; 
    //Set other properties 

    //Not sure of nunit syntax here, so I will make something up. 
    Assert.IsNotEmpty(user.Email); 

} 

Answer 1

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

Теперь вернемся к вопросу. Как вы тестируете свой уровень доступа к базе данных? Они называются интеграционными тестами. Существует множество методов для проведения интеграционных тестов с базой данных. Некоторые из них состоят из тестовой базы данных, которая воссоздана в методе установки и упала в методе TearDown, так что все тесты предполагают некоторое действительное состояние для работы. Таким образом, у вас могут быть сценарии, которые создают и заполняют базу данных тестовыми данными, и эти сценарии вызывают перед запуском каждого теста. Вы можете даже обернуть все внутри транзакции базы данных, которая будет откат в конце.

Answer 2

Ну, это зависит от того, что вы пытаетесь выполнить «единицей».

• Вы проверяете бизнес-логику, которая проверяет, что созданный пользователь действителен?
• Вы тестируете уровень доступа к базе данных (код доступа БД и/или сохраненные процедуры)?
• Вы хотите проверить оба одновременно?

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

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

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

Answer 3

Я не думаю, что вы действительно имеете в виду «единичный тест» в строгом смысле этого слова (с использованием базы данных или всего остального за пределами самого метода, что делает ее «интеграционным»), но если бы я создавал автоматическую test для метода, который вы упомянули, я бы сделал тест, который создает объект User, передает его в метод Register, а затем извлекает пользователя из базы данных и проверяет его на исходный объект, чтобы убедиться, что он точно такой же. Последний шаг, вероятно, будет включать некоторые вызовы Assert.

Другие тесты - проверка нулевого параметра, чтобы увидеть, что происходит при передаче нулевого объекта и, возможно, некоторые тесты, которые используют различные виды «странных» данных, чтобы увидеть, как метод обрабатывает все ваши варианты использования ,