Есть ли значение в модульном тестировании автоматически реализованных свойств

Это кажется исключительно жестким, но, следуя правилу , следует проверять все общедоступное, следует ли проверять автоматически реализуемые свойства?

Класс клиента

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 ответов

Решение

Что произойдет, если вы перейдете от автоматически реализованных свойств к чему-то совершенно другому? Тест кажется избыточным только потому, что вы знаете реализацию, которую вы не должны учитывать при написании тестов.

Конечно, это зависит от вероятности того, что вы действительно измените реализацию в ближайшее время.

Источник

Я вообще считаю, что любой код, который не выполняет действия, не стоит тестировать. Обычно это означает, что я не проверяю свойства (автоматически реализованные или нет), потому что они просто устанавливают или возвращают значение.

Это изменится, если получатель или установщик свойства выполняет какую-то "работу", например, возможно, возвращает одно из двух (или более) значений в зависимости от состояния какого-либо другого поля / свойства / чего бы то ни было.

Если вы этого не видели, я настоятельно рекомендую книгу Роя Ошерова о модульном тестировании. В нем рассматриваются всевозможные вопросы типа "что тестировать и когда", включая этот.

Источник

Тестирование установки и получения свойств должно происходить в контексте тестирования бизнес-функции объекта. Если нет бизнес-функции, тестирующей свойство, то либо вам не нужно это свойство, либо вам нужно больше тестов. Я бы посоветовал вам добавлять свойства по мере добавления нужных вам тестов, а не добавлять их до написания каких-либо тестов.

Тестируя бизнес-функцию, вы рассматриваете код как нечто большее, чем черный ящик с точки зрения модульного теста. Это позволяет переключаться между деталями реализации с гораздо меньшим влиянием на тесты. Поскольку Refactor является важной (и часто упускаемой из виду) стадией цикла TDD, это означает гораздо меньше редактирования кода. Вы также можете понять, что (например) свойство не должно иметь общедоступного установщика и должно назначаться методом, который выполняет проверку и другую бизнес-логику.

Источник

Это зависит от того, тестируете ли вы, что API соответствует ожидаемому набору свойств, или, как вы демонстрируете, вы просто тестируете доступ и установку свойств.

В приведенном вами примере я бы сказал нет.

Обновить

Соответствует ожидаемому API; если вы обращаетесь к свойствам косвенно, скажем, в отражающей / динамической среде, и вы используете вызовы доступа к свойствам и методам для проверки того, что неизвестный API соответствует ожидаемому.

Источник

Модульное тестирование должно ограничиваться функциональностью тестирования, которую вы реализуете в своем приложении.

Вы не должны тестировать API/SDK, на которые опирается ваше приложение. Частично потому, что это пустая трата времени (хочет ли ваша компания заплатить за то, чтобы вы тестировали SDK/API X-Third-Party?), А отчасти потому, что это вносит "шум" в ваш пакет модульных тестов. Контекст вашей библиотеки модульных тестов должен состоять в том, чтобы просто тестировать только код в вашем приложении.

Источник
Другие вопросы по тегам