Есть ли значение в поблочном тестировании автоматические реализованные свойства
Это кажется исключительно жестоким, но идущий правилом что-либо общедоступное должно быть протестировано, автореализованные свойства должны быть протестированы?
Клиентский класс
public class Customer
{
public string EmailAddr { get; set; }
}
Протестированный
[TestClass]
public class CustomerTests : TestClassBase
{
[TestMethod]
public void CanSetCustomerEmailAddress()
{
//Arrange
Customer customer = new Customer();
//Act
customer.EmailAddr = "foo@bar.com";
//Assert
Assert.AreEqual("foo@bar.com", customer.EmailAddr);
}
}
5 ответов
Что произойдет, если вы переключитесь с автореализованных свойств на что-то совершенно другое? Тест кажется избыточным только потому, что вы знаете реализацию - что не следует учитывать при написании тестов.
Конечно, это зависит от вероятности того, что вы действительно измените реализацию в ближайшее время.
Тестирование установки и получения свойств должно происходить в контексте тестирования бизнес-функции объекта. Если нет бизнес-функции, тестирующей свойство, то либо свойство не нужно, либо нужно больше тестов. Я бы предложил добавлять свойства по мере добавления тестов, которым они нужны, а не добавлять их до написания тестов.
Тестируя бизнес-функцию, вы обращаетесь с кодом как с "черным ящиком" с точки зрения модульного теста. Это позволяет вам менять детали реализации под ними с гораздо меньшим влиянием на тесты. Поскольку рефактор является важным (и часто упускаемым из виду) этапом цикла TDD, это означает гораздо меньше редактирования кода. Вы также можете понять, что (например) свойство не должно иметь публичного сеттера и должно быть назначено методом, выполняющим проверку и другую бизнес-логику.
Я обычно считаю, что любой код, который не выполняет какого-либо действия, не стоит тестировать. Это обычно означает, что я не тестирую свойства (автореализованные или нет), потому что они просто устанавливают или возвращают значение.
Это изменится, если геттер или сеттер свойства выполняет какую-то "работу", например, может возвращать одно из двух (или более) значений на основе состояния какого-то другого поля/свойства/чего угодно.
Если вы еще не видели ее, я очень рекомендую книгу Роя Ошерова о модульном тестировании . В ней рассматриваются всевозможные вопросы типа "что тестировать и когда", включая этот.
Это зависит от того, проверяете ли вы соответствие API ожидаемому набору свойств, или, как вы демонстрируете, вы просто тестируете доступ к свойствам и их установку.
В приведенном вами примере я бы сказал нет.
Обновление
Соответствие ожидаемому API; если вы обращаетесь к свойствам косвенно, скажем, в среде отражения / динамической среды, и используете вызовы доступа к свойствам и методам для проверки соответствия неизвестного API ожидаемому.
Модульное тестирование должно ограничиваться функциональностью тестирования, которую вы реализуете в своем приложении.
Вы не должны тестировать API / SDK, на котором основано ваше приложение. Отчасти потому, что это пустая трата времени (хочет ли ваша компания платить за тестирование X-Third-Party SDK / API?), А отчасти потому, что это вносит «шум» в ваш набор модульных тестов. Контекст вашей библиотеки модульных тестов должен заключаться в том, чтобы просто тестировать только код в вашем приложении.