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

Question

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

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

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);
    }
}

Answer 1

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

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

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

Answer 2

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

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

Answer 3

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

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

Answer 4

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

Обновление

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

Answer 5

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

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