Модульное тестирование объекта значения

Question

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

Возьмем, к примеру, этот объект:

public class TeamProfile
{
    public string Name { get; set; }

    public int Wins { get; set; }
    public int Losses { get; set; }
    public int Draws { get; set; }
}

Answer 1

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

Я бы судил исходя из конкретной ситуации. Если вы думаете, что «мои процедуры модульного тестирования все-таки проверяют все» (и полагаются на это), и вы видите, что любая из вышеперечисленных процедур может когда-нибудь измениться на что-то более сложное, тогда ответ - ДА. На подобные вопросы я иногда отвечаю «ДА», чтобы через некоторое время выяснить, что это действительно излишне. Затем в других случаях я сужу: «О, нет, это действительно излишне», но позже я узнаю, что был аспект, о котором я никогда не думал.

Как это проверить? Как и во всех тестовых примерах: определите ввод и ожидаемый результат. Установить его. Возьми. Проверьте, есть ли у вас то, что вы установили.

Answer 2

Я не думаю, что это «необходимо» само по себе, но это вас охраняет, если вы в какой-то момент добавляете логику в свои сеттеры (например: выбрасываете исключение, когда предпринимаются отрицательные выигрыши / проигрыши / ничьи, поскольку вы 'не использует беззнаковые целые).

Как это проверить?Просто: вызовите установщик, вызовите получатель, убедитесь, что значение соответствует тому, что вы сохранили, или выдается исключение, которое вы ожидали.

Answer 3

Дэн Берг Джонссон (Dan Bergh Johnsson) опубликовал отличную статью об объектах значений, их представлении и тестировании. http://www.infoq.com/presentations/Value-Objects-Dan-Bergh-Johnsson

Для ясности я должен повторить, что приведенный пример не объект значения. http://martinfowler.com/bliki/ValueObject.html

Это, в частности, команда, сообщение или, скорее, объект передачи данных (DTO). Как уже упоминалось, предоставленный класс не имеет поведения для тестирования.

Answer 4

Я бы протестировал функциональность, которая больше, чем просто получить / установить. Например, объекты-значения должны переопределять Equals и GetHashCode.

Если вы думаете о модульном тесте как о кодированной функциональной спецификации, это может помочь вам придумать необходимые тесты. (Если у вас действительно есть функциональная спецификация, то это хороший источник для определения модульных тестов.)

Answer 5

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

Не забудьте добавить тест отсутствует , как только вы измените сигнатуру сортировки.

Answer 6

Это можно сделать, но совершенно бесполезно ИМО.
Объекты-значения не содержат абсолютно никакой логики, и поэтому их тестирование - пустая трата усилий (и почти все другие тесты будут ломаться, если ваши объекты-значения сломаны, учитывая, что вы никогда не насмехаетесь над ними). ​​