Могу ли я сделать это в моих модульных тестах?

Question

Я не уверен, что мне здесь делать. Должен ли я жестко кодировать все значения в переменных CONST. Все, что я видел, похоже, жестко закодировало значения, поэтому я не уверен.

Как будто это то, что я делал сейчас.

Скажите, в моем контроллере у меня был проверочный тест, чтобы проверить, пытается ли пользователь отправить форму с пустым полем.

Теперь у меня будет оператор if, проверяющий пустую или нулевую переменную. Если это произойдет, я добавлю ошибку в ModelState с сообщением об ошибке, которое я написал.

поэтому в моем модульном тесте я хочу убедиться, что, если передана пустая переменная формы, она будет перехвачена.

теперь в моем модульном тестировании я просто сделал переменную CONST, скопировал и вставил сообщение проверки.

Итак, в моем утверждении я сравниваю реальное сообщение с сообщением, хранящимся в моем CONST Varrible. Я делаю это, вызывая состояние модели и вызываю поле, в котором, как я ожидаю, будет ошибка.

Как:

.

result.ViewData.ModelState [ "имя пользователя"] Ошибки [0];

Так что, если сообщение есть, значит, оно должно было войти в мой код, иначе оно не существовало бы.

Так что мне пришло в голову, может быть, мне следует создать новый класс, который будет статическим и содержать все эти переменные CONST.

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

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

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

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

Для меня это имеет смысл, но я подумал, что лучше сначала проверить.

Спасибо

Answer 1

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

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

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

Когда я читаю ваш вопрос, вы уже начинаете видеть контуры этого анти-паттерна. Я предполагаю, что именно поэтому вы проверяете не конкретные возвращенные тексты, а только то, установлены ли они вообще. Я думаю, что это правильно - я редко проверяю конкретные строки, а скорее, указана ли строка вообще. Это делает тест более устойчивым к изменениям, и вы избегаете анти-паттерна Overspecified Test.

Во многих случаях вместо выполнения Assert.AreEqual для двух строк вы можете просто использовать Assert.IsNotNull или, возможно, Assert.IsFalse(string.IsNullOrEmpty(result)) (ваша платформа выглядит как .NET).

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

• Производные значения гарантируют выполнение спецификации

Если вы чувствуете себя особенно предприимчивым, я могу только порекомендовать вам прочитать xUnit Test Patterns , откуда берутся многие шаблоны и антишаблоны, о которых я упоминал. Искусство юнит-тестирования тоже хорошо ...

Answer 2

«Должен ли я жестко кодировать все значения в переменных CONST.»

Я не уверен, что вы имеете в виду. Хорошо иметь константные переменные в классе модульного теста. E.g.:

class FooTest
{
    private static readonly string FOO_MESSAGE = "BAR"; 

или

    public static const string BAZ_MESSAGE = "BOO";

...

    Assert.AreEqual(FOO_MESSAGE, e.ToString());
}

"Так что мне пришло в голову, может быть, мне следует создать новый класс, который будет статическим и содержать все эти переменные CONST.

Таким образом, как представления контроллера, так и модульные тесты могут использовать их. Таким образом, если мне нужно изменить сообщение об ошибке, мне нужно изменить его только в одном месте. "

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

«Поскольку я не проверяю сообщение об ошибке, я проверяю, установлено ли оно.»

Если вы действительно не тестируете сообщение, зачем тесту об этом знать?