Assert.Fail () считается плохой практикой?

Question

Я использую Assert.Fail много при выполнении TDD. Обычно я работаю над одним тестом за раз, но когда я получаю идеи для вещей, которые я хочу реализовать позже, я быстро пишу пустой тест, где имя метода теста указывает, что я хочу реализовать в виде своего списка задач. Чтобы не забыть, я поместил Assert.Fail () в тело.

При тестировании xUnit.Net я обнаружил, что они не реализовали Assert.Fail. Конечно, вы всегда можете Assert.IsTrue (false), но это также не говорит о моих намерениях. У меня сложилось впечатление, что Assert.Fail не был реализован специально. Это считается плохой практикой? Если так, то почему?

---

@ Мартин Мередит Это не совсем то, что я делаю. Сначала я пишу тест, а затем реализую код, чтобы он заработал. Обычно я думаю о нескольких тестах одновременно. Или я думаю о тесте, чтобы написать, когда я работаю над чем-то другим. Вот тогда я и напишу пустой провальный тест, чтобы запомнить. К тому времени, когда я приступаю к написанию теста, я аккуратно начинаю тестирование.

@ Jimmeh Это похоже на хорошую идею. Проигнорированные тесты не терпят неудачу, но они все еще отображаются в отдельном списке. Должен попробовать это.

@ Мэтт Хауэллс Отличная идея. NotImplementedException сообщает о намерении лучше, чем assert.Fail () в этом случае

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

Answer 1

Я думаю, вы должны спросить себя, что должно делать (предварительное) тестирование.

Сначала вы пишете (набор) тестов без имплементации. Может быть, и сценарии дождливого дня.

Все эти тесты должны быть неудачными, чтобы быть правильными: Итак, вы хотите достичь двух вещей: 1) Убедитесь, что ваша реализация верна; 2) Убедитесь, что ваши юнит-тесты верны.

Теперь, если вы делаете предварительный TDD, вы хотите выполнить все свои тесты, в том числе и части NYI. Результат вашего полного теста проходит, если: 1) Все реализованные вещи успешны 2) Все вещи NYI терпят неудачу

В конце концов, это было бы пропуском модульных тестов, если бы ваши модульные тесты были успешными, пока нет реализации, не так ли?

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

Просто напишите [игнорировать] тесты, которые не будут выполнять работу. Кроме того, подтверждение, которое останавливает первый сбой утверждения, не запускает другие строки теста в тесте.

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

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

Идея состоит в том, чтобы разбить ваши тесты на несколько сборок, использовать группировку тестов (упорядоченные тесты в mstest могут выполнять эту работу).

Тем не менее, сборка CI, которая отправляет по почте, если не все тесты в отделении NYI, неудачи, не проста и прямолинейна.

Answer 2

MS Test имеет Assert.Fail () , но также имеет Assert.Inconclusive () . Я думаю, что наиболее подходящее использование для Assert.Fail () - это если у вас есть некоторая встроенная логика, которую было бы неудобно вставлять в утверждение, хотя я даже не могу придумать ни одного хорошего примера. По большей части, если тестовая среда поддерживает что-то отличное от Assert.Fail (), используйте это.

Answer 3

Если вы пишете тест, который просто не проходит, а затем пишете код для него, тогда пишите тест. Это не тестовая разработка.

Технически, Assert.fail () не требуется, если вы правильно используете тестовую разработку.

Задумывались ли вы об использовании списка Тодо или о применении методологии GTD к вашей работе?