Любой код может обеспечивать побочные эффекты. Большую часть времени побочные эффекты могут быть признаком плохой конструкции и/или необходимости рефакторизации, но при модульном тестировании мне сложно протестировать. Рассмотрим следующий пример:Есть ли способ провести единичный тест против побочных эффектов?
[Test]
public void TrimAll_Removes_All_Spaces()
{
// Arrange
var testSubject = "A string with lots of space";
var expectedResult = "Astringwithlotsofspace";
// Act
var result = testSubject.TrimAll();
// Assert
Assert.AreEqual(expectedResult, result);
}
, который проверяет следующее расширение:
public static string TrimAll(this string str)
{
PokeAround();
return str.Replace(" ", "");
}
тест пройдет, но нет никаких защитных Agains побочных эффектов. Эффекты вызова на PokeAround будут полностью незаметны.
Учитывая, что вы не знаете, что такое PokeAround - это может быть что угодно! - Как вы пишете тест, который защищает его? Возможно ли это?
Разъяснение: Там было несколько замечаний по поводу PokeAround как совершенно неизвестно, что это очень маловероятный сценарий, так как у нас есть источник, когда мы пишем тест. Причина, по которой я задала этот вопрос, заключалась в том, чтобы найти способ защиты от побочных эффектов, добавленный позже на. То есть, когда я пишу тест, я мог бы иметь метод exension выглядеть следующим образом:
public static string TrimAll(this string str)
{
return str.Replace(" ", "");
}
тест проходит, все это хорошо. Затем, через месяц, когда я нахожусь в отпуске, коллега добавит звонок PokeAround. Я хочу, чтобы тест, который я уже написал, терпел неудачу, потому что он это сделал.
Вопрос не имеет значения. Вы не можете установить тестовый код, к которому у вас нет доступа. «В компьютерном программировании модульное тестирование - это метод, с помощью которого тестируются отдельные единицы исходного кода, чтобы определить, подходят ли они для использования. Единица является наименьшей проверяемой частью приложения. В процедурных программах единица может быть индивидуальной функции или процедуры. Модульные тесты создаются программистами или иногда с помощью тестеров с ящиками белого цвета ». – WOPR
@WOPR: Посмотрите мое обновление для реального сценария, где это актуально. –
Это по-прежнему бессмысленно. Теперь вы пытаетесь расширить концепцию модульного тестирования, чтобы предотвратить идиотизм у других программистов. Ваш «будущий коллега» должен был также проверить его изменения. Вы не можете использовать модульное тестирование для проверки будущих изменений ... он мог бы просто удалить весь ваш код и изменить его, чтобы удалить главную загрузочную запись. – WOPR