Почему делает “Утверждать” класс, имеют столько на вид избыточных методов? Когда каждый должен использоваться?
Таким образом, я вижу, что Утверждают, имеет десятки методов, которые, кажется, делают по существу то же самое.
Assert.IsFalse( a == b );
Assert.IsTrue( a != b );
Assert.AreNotEqual( a, b );
Почему? Это должно только быть более явно? Когда различные методы должны использоваться? Существует ли официальный документ лучших практик?
6 ответов
Разница между IsFalse и IsTrue заключается в удобочитаемости. AreNotEqual позволяет лучше отображать сообщение об ошибке, когда тест не проходит. IsTrue , например, просто скажет вам, что ответ должен был быть истинным, а на самом деле был ложным. AreNotEqual покажет два значения, которые сравнивались в его сообщении об ошибке.
Для еще одного примера фактического использования союзов фреймворк CORBA сериализует объекты с использованием метода объединения с тегами. Все определяемые пользователем классы являются членами одного (огромного) объединения, и целочисленный идентификатор сообщает демаршалеру, как интерпретировать объединение.
-121--593617-В соответствующем объекте ответа возвращается "id", поэтому можно сопоставить один контекст с другим.
Если вы выполняете синхронные одиночные вызовы, это может не иметь смысла, но в асинхронной среде с несколькими выдающимися вызовами это жизненно важно.
Он не должен быть жестко закодирован для 1, а должен иметь уникальное значение для каждого объекта запроса, создаваемого клиентом.
-121--1740777-Краткий ответ: Для читаемости.
Немного более длинный ответ:
Ваши тесты также являются кодовыми, и с точки зрения намерений так же важны, как и тестируемый код. Таким образом, необходимо максимально четко определить цель теста. Иногда это означает использование IsFalse , иногда - использование IsTrue .
Эти три метода преследуют три разные конкретные цели. Цель тестирования - обеспечить четкую проверку и валидацию вашего кода. Используя наиболее четкий и конкретный метод, вы делаете свой тест наименьшим из возможных, с наиболее конкретным и ясным значением.
Это помогает, потому что добавляет ясности - вы можете видеть, что конкретно должен делать тест в более декларативной форме, в то время как использование одного и того же метода для нескольких сценариев тестирования, каждый из которых имеет разное значение, требует большего понимания самого кода, а не природы теста.
В этом случае третий метод является (единственным) подходящим для использования. Однако, если бы у вас была такая ситуация, вы бы использовали другой метод, например:
Assert.IsTrue( myClass.MethodThatReturnsTrue() );
Вы должны использовать тот метод, который обеспечивает наибольшую ясность относительно вашей цели - если вы проверяете два значения на равенство, используйте Assert.IsEqual, если вы проверяете булево значение на ложность, используйте Assert.IsFalse. Это делает отчеты об ошибках осмысленными и понятными.
Нет, оба эквивалентны в конце. Я лично склонен использовать нотацию со знаком @ , чтобы быть совместимым с кодом T-SQL для хранимой процедуры, которую я пишу.
Но насколько мне известно, оба метода подходят для приложений .NET, взаимодействующих с SQL Server.
-121--4028598-То, что вы хотите сделать, звучит немного как проверка модели , с одной стороны, и автоматическое создание тестового случая, с другой стороны (в последней категории проверка Concolic test , метод, чтобы избежать потери времени при неосуществимом выполнении
Проверка модели была бы предпочтительным методом, если вы предполагаете, что ваше веб-приложение правильно и хотите доказать, что это так. Но в случае предупреждения, возможно, вам придется работать, чтобы понять, является ли проблема реальной или нет. это не доказывает, что ваше приложение правильно, но если оно находит проблему, оно дает вам входной вектор, чтобы создать его, так что вам не нужно задумываться, является ли проблема реальной.
Я не знаю ни о каких существующих инструментах для веб-приложений, но это не означает, что они не существуют.
-121--1948915-Ошибки легче всего прочитать; используйте тот, который наиболее точно соответствует вашему коду.
В этом случае используйте No3.
Потому что вы можете перегрузить == и! =, Вот почему.
Это называется "Fluent Interface"... и, по мнению многих, делает вещи более читаемыми.