Какие модульные тесты должны быть написаны для простых объектов домена POCO?

Question

Таким образом, стандартная философия Agile рекомендует делать классы вашего домена простыми POCO, которые сохраняются с использованием отдельного уровня прокси через объекты доступа к данным (как это делает NHibernate). Он также рекомендует получить максимально возможное покрытие модульных испытаний.

Имеет ли смысл писать тесты для этих простых объектов POCO? Скажем, у меня есть класс, который выглядит так:

public class Container {
 public int ContainerId { get; set;}
 public string Name { get; set;}
 public IList<Item> Contents { get; set;}
}

Какие полезные юнит-тесты можно написать для этого?

Answer 1

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

Модульные тесты предназначены для проверки поведения. Нет поведения? Нет необходимости в тесте.

Answer 2

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

Например, может ли ContainerId быть меньше нуля? Было бы ошибкой пытаться установить его в отрицательное значение? Должна ли коллекция инициализироваться конструктором, т. Е. Должны ли классы, использующие этот контейнерный класс, проверять наличие нуля перед обращением или вы хотите гарантировать, что коллекция никогда не будет нулевой, хотя она может быть пустой?

Тем не менее, я обычно применяю здравый смысл в этом процессе. Например, если я знаю, что конструктор имеет внутреннюю область видимости, а объекты создаются только классом Factory. Я протестирую фабричные методы, чтобы убедиться, что они всегда создают допустимые объекты, но не обязательно проверяют сам класс контейнера.

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

Answer 3

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

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

Answer 4

Мне нравится думать о модульном тесте как о «вызове» единицы намерения.

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

Никаких других намерений не выражено, поэтому тесты не требуются.

Однако я бы предложил удалить сеттер из свойства Contents. Свойства коллекции должны быть доступны только для чтения.

Answer 5

Я бы сказал, что это даже не объект - и объект определяется его поведением, а у этого класса его нет. Это чистый контейнер данных. Это тоже нормально, и они, как правило, не нуждаются в каких-либо тестах, но будьте осторожны, что у вас не останется модель анемичного домена . Использование Test Driven Development «заставит» вас задуматься о поведении ваших классов, и это может быть хорошим упражнением.