UnitTesting Свойства в .Net?

Question

Я работаю над библиотекой, которую хочу выпустить с открытым исходным кодом. Я начал писать тесты для кода, и мне было интересно, как я должен тестировать свойство в объекте .Net. Допустим, у меня есть следующее:

public class Person{
    #region variables
    private string _name = String.Empty;
    private string _surname = String.Empty;
    #region properties
    public string Name{
        get{
             return _name;
        }
    }
    public string Surname{
        get{
            return _surname;
        }
        set{
            _surname = value;
        }
    }
}

У меня есть два вопроса, связанных с кодом:

1. Как мне провести модульное тестирование свойства, в котором есть только геттер (например, как в названии)
2. Как мне провести юнит-тестирование свойства с помощью сеттера и геттера (как, например, фамилия в примере)

Я хочу протестировать свойства, которые настолько просты, потому что я уже нашел ошибки в другом коде, где Itellinsense сделал неправильное автозаполнение и свойство не возвращало правильную переменную.

Обновление:

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

Answer 1

Не тратьте свое время на глупые письма тесты для геттеров и сеттеров.

Другой тест, вероятно, установит Имя, а затем получить это свойство, чтобы вы будет иметь покрытие кода для добытчик.

Вам следует протестировать все, что доступно для общественности, включая свойства. Если вы не тестируете свойство, вы рискуете, что кто-то может добавить в него какую-то логику, нарушая функциональность.

Кроме того, вы не должны полагаться на то, что он тестируется в других тестах. Это делает ваши тесты хрупкими и затрудняет определение проблемы, так как тест будет тестировать более чем одну вещь.

Answer 2

Как мне протестировать свойство, которое просто есть получатель (как имя в пример)

Действительно не сильно отличается от тестирования, если у вас был сеттер. вам просто нужно найти другой способ определения выхода. Может быть в ctor или в результате других сеттеров / операций над объектом.

[Test]
public void NamePropTest()
{
    Person p = new Person();

    //Some code here that will set up the Person object
    //  so that you know what the name will be

    Assert.AreEqual("some known value...", p.Name);
}

Если бы у нас были сеттеры для Name и SurName, но только геттеры для FullName, тест мог бы выглядеть так:

[Test]
public void NamePropTest()
{
    Person p = new Person();

    p.Name = "Sean";
    p.Surname = "Penn";

    Assert.AreEqual("Sean Penn", p.FullName);
}

Answer 3

Вы должны проверить свойства. Также автоматические свойства!

Юнитестесты - это гарантия того, что изменения в программе не нарушат ее.

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

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

РЕДАКТИРОВАТЬ: (В ответ на комментарий шахкальпеша ...)

Если вы меняете реализация, тесты могут также требовать изменения. Итак, я не знаю почему кто-то должен тестировать просто получить / установить?

Начиная с этого класса:

public class TimeOfDay
{
    public int Hour{get; private set;}
    public int Minute{get; private set;}

    public TimeOfDay(int hour, int minute)
    {
        Hour = hour;
        Minute = minute;
    }
}

При изменении реализации тесты остаются в силе!

public class TimeOfDay
{
    public int _minutesSinceMidnight = 0;

    public int Hour
    {
        get { return _minutesSinceMidnight / 60; }
        set { _minutesSinceMidnight = value * 60 + Minutes; }
    }

    public int Minute
    {
        get { return _minutesSinceMidnight % 60; }
        set { _minutesSinceMidnight = Hour * 60 + value; }
    }

    public TimeOfDay(int hour, int minute)
    {
        Hour = hour;
        Minute = minute;
    }
}

Добавьте некоторые арифметические функции даты и времени или что-то еще, и я хотел бы, чтобы тесты показали, что все по-прежнему работает ...

Answer 4

Я думаю, вы должны проверить их, если вы напишите их, как вы. В конце концов, вы можете что-то напечатать.

Просто что-то вроде

var person = New Person();
person.Surname = "test";
Assert.AreEqual("test", person.Surname);

После всех тестов TDD и модульных тестов, в общем, нужно избегать как можно больше ошибок.

Если вы случайно написали это.

public class Person{
    #region variables
    private string _name = String.Empty;
    private string _surname = String.Empty;
    #region properties
    public string Name{
        get{
             return _name;
        }
    }
    public string Surname{
        get{
            return _name;
        }
        set{
            _name = value;
        }
    }
}

тогда у вас будет ошибка.

Тестирование автоматических свойств, возможно, менее ценно. Но это другой вопрос.

Answer 5

Я думаю, что вы имели в виду, что ваше свойство только для получателя использует личные поля или другие личные данные. Если вам нужно установить их, единственный способ - получить их по Reflection (см. Все (что-то) классы Info в System.Reflection). Но есть хорошая дискуссия, если это хорошая практика.

Answer 6

Мой вопрос больше связан с тем, КАК написать тест. я думал об этом, и мне нужно получить доступ к частные ценности, чтобы убедиться, что свойства работают как положено, иначе Я не знаю как это сделать. https://stackoverflow.com/users/59332/mandel

Хорошо ... так как вы настаиваете на том, чтобы знать, как это сделать ...

[Test]
TestMethod()
{

    Person p = new Person();
    p.Name = "a name";
    p.Surname = "a surname";

    Assert.That(p.Name, Is.EqualTo("a name"));
    Assert.That(p.Surname, Is.EqualTo("a surname"));
}

Однако, это работает, только если у вас есть сеттеры ...

Если у вас есть только добытчики, я могу думать о том, что вы можете сделать это только двумя способами.

1. заранее знать возвращаемое значение и утверждать против этого.
2. Используйте Reflection, чтобы установить значение, а затем применить его к этому известному значению.

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

Answer 7

Не тратьте свое время на написание глупых тестов для геттеров и сеттеров.

Другой тест, вероятно, установит Имя, а затем получит это свойство, так что вы получите покрытие кода для получателя.

Answer 8

Как я понимаю, вы не должны тестировать свойства (то есть те, которые просто получают / устанавливают).

Я не уверен, какую версию c # вы используете. Но вы можете использовать автоматические свойства, чтобы избежать простых проблем с установкой / получением, с которыми вы сталкиваетесь.

См. ссылку

Answer 9

Это свойство должно быть там, потому что у вас есть обычаи, которые в них нуждаются. Что касается этих, должны быть модульные тесты, у вас уже должно быть покрытие для них. Если нет сценария, который нуждается в них, возможно, их вообще не должно быть.