Любой код может обеспечивать побочные эффекты. Большую часть времени побочные эффекты могут быть признаком плохой конструкции и/или необходимости рефакторизации, но при модульном тестировании мне сложно протестировать. Рассмотрим следующий пример:
[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(" ", "");
}
Тест пройдет, но побочных эффектов защиты снова нет. Эффекты вызова PokeAround будут полностью незаметны.
Учитывая, что вы не знаете, что PokeAround - это может быть что угодно! - Как вы пишете тест, который защищает его? Возможно ли это?
Разъяснение:
Было несколько комментариев о PokeAround, поскольку совершенно неизвестный был очень маловероятным сценарием, так как у нас есть источник, когда мы пишем тест. Причина, по которой я задавала этот вопрос, заключалась в том, чтобы найти способ защиты от побочных эффектов, добавленных позже. То есть, когда я пишу тест, у меня может быть метод exension следующим образом:
public static string TrimAll(this string str)
{
return str.Replace(" ", "");
}
Тест проходит, все хорошо. Затем, через месяц, когда я нахожусь в отпуске, коллега добавит вызов PokeAround. Я хочу, чтобы тест, который я уже написал, терпел неудачу, потому что он это сделал.
