ASP.NET MVC - Излишество поблочного тестирования? (TDD)
Так как бедствие (как 9/11) может полностью , уничтожают центр обработки данных, это означает, что DR является процессами восстановления всего для того центра обработки данных?
5 ответов
Все зависит от того, какой объем покрытия вам нужен / вы хотите и насколько надежность является проблемой.
Вот вопросы, которые вы должны задать себе:
- Помогает ли этот модульный тест реализовать изменение функции / кода, которого у меня еще нет?
- Поможет ли этот модульный тест регрессивному тестированию / отладке этого модуля, если я внесу изменения позже?
- Является ли код, удовлетворяющий этому модульному тесту, нетривиальным, или он заслуживаете модульного теста?
Что касается третьего, я помню, когда я начал писать модульные тесты (я знаю, это не то же самое, что TDD), у меня были тесты, которые выглядели бы так:
string expected, actual;
TypeUnderTest target = new TypeUnderTest();
target.PropertyToTest = expected;
actual = target.PropertyToTest;
Assert.AreEqual<string>(expected, actual);
Я мог бы сделать что-то большее продуктивно потратить свое время, например, выбрать лучшие обои для рабочего стола.
Я рекомендую эту статью автора книги ASP.net MVC Сандерсона:
http: //blog.codeville.net / 2009/08/24 / writing-great-unit-tests-best-and -hest-practice /
Я бы сказал, что вы делаете немного больше, чем вам, вероятно, нужно. Хотя неплохо тестировать каждый возможный путь, по которому может идти ваш код, некоторые пути просто не очень важны или не приводят к реальным различиям в поведении.
В вашем примере возьмите LogOn (string returnUrl)
Первое, что вы делаете, это проверяете параметр returnUrl и повторно присваиваете ему значение по умолчанию, если он пустой / пустой. Вам действительно нужен целый модульный тест, чтобы убедиться, что одна строка кода выполняется должным образом? Это не та линия, которая легко сломается.
Большинство изменений, которые могут нарушить эту строку, могут вызвать ошибку компиляции. В этой строке возможно изменение присвоенного значения по умолчанию (возможно, позже вы решите, что "/" не является хорошим значением по умолчанию ... но в вашем модульном тесте Бьюсь об заклад, вы жестко запрограммировали его, чтобы проверять "/", не так ли? Таким образом, изменение значения потребует изменения вашего теста ... что означает, что вы не тестируете свое поведение, вместо этого вы тестируете свои данные.
Вы можете выполнить тест поведения метода, просто имея один тест, который НЕ предоставляет параметр. Это затронет вашу часть процедуры, "установленную по умолчанию", при этом все еще будет проверяться, что остальной код тоже ведет себя хорошо.
100% покрытие очень идеально, его это действительно полезно, если вам нужно провести массовый рефакторинг вашего кода, поскольку тесты будут определять ваши спецификации кода, чтобы убедиться, что он правильный.
Лично я не на 100% TDD (иногда тоже слишком ленив), но если вы собираетесь сделать 100%, возможно, вам стоит написать несколько помощников по тестированию, чтобы снять некоторую нагрузку на эти повторяющиеся тесты. Например, напишите помощник для тестирования всего вашего CRUD в стандартной структуре сообщений с обратным вызовом, чтобы вы могли пройти некоторую оценку, и это может сэкономить вам много времени.
Это похоже на меня. Да, вы напишете много модульных тестов, и поначалу это покажется излишним и пустой тратой времени; но придерживайтесь этого, оно того стоит. То, к чему вы должны стремиться (а не просто 100% покрытие кода), - это 100% покрытие функций. Однако ... если вы обнаружите, что пишете много UT для одного и того же метода, возможно, этот метод делает слишком много. Постарайтесь больше разделять свои проблемы. По моему опыту, основная часть Action'а должна делать не что иное, как новичок в классе для выполнения настоящей работы. Это тот класс, на который вы действительно должны нацеливаться с помощью UT.
Chris
Я тестирую только код, в котором я не уверен. Конечно - никогда не знаешь, что нанесет тебе удар, но написание тестов на тривиальные вещи кажется мне излишним.
Я не гуру модульного тестирования / tdd - но я думаю, что это нормально, если вы НЕ пишете тесты только для того, чтобы иметь их. Они должны быть полезны. Если у вас достаточно опыта в модульном тестировании - вы начнете почувствовать , когда они будут полезными, а когда нет.
Вам может понравиться эта книга .
Изменить:
На самом деле - я только что нашел цитату об этой главе под главой, посвященной изоляционным каркасам. Речь идет о переопределении тестов (один конкретный тест), но я полагаю, что идея остается в более глобальном масштабе:
Переопределение тестов
Если ваш тест имеет слишком много ожиданий, вы можете создать тест, который ломается даже при малейших изменениях кода, даже если общая функциональность по-прежнему работает. Считайте это более техническим способом не проверять правильные вещи. Тестирование взаимодействий - это обоюдоострый меч: слишком много проверяйте, и вы начинаете терять из виду общую картину - общую функциональность; проверить это слишком мало, и вы пропустите важные взаимодействия между объектами.