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