Как мне провести юнит-тестирование простого CRUD-класса?

Question

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

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

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

Создать

1. Введите некоторые соответствующие параметры (название продукта и т. Д.)
2. Убедитесь, что личность возвращена.
3. Удалить продукт (очистить).

Чтение

1. Создать новый продукт
2. Вызовите метод выбора
3. Убедитесь, что название продукта совпадает с тем, которое я дал при создании
4. Удалить продукт

Обновление

1. Создать новый продукт
2. Обновить некоторые поля на нем
3. Выберите товар
4. Убедитесь, что некоторые поля совпадают
5. Удалить продукт

Удалить

1. Создайте новый продукт, сохраните ProductID
2. Удалить продукт (Очистка в проходе 4!)
3. Проверить, находится ли продукт с этим Productid в таблице?

EDIT:

... Или я должен просто создать одиночный тест, который проверяет все эти вещи?

Answer 1

Я прошел этот путь, и вот все проблемы, с которыми вы столкнетесь:

1) Это выглядит хорошо для одной записи, но что произойдет, когда вам понадобятся 4 другие записи для создания этой записи? Вы заканчиваете тем, что создали 4 записи, чтобы проверить вставку одной записи. Это вызывает все следующие проблемы.

2) Создание и удаление 4-5 записей за тест выполняется медленно, оно будет медленно складываться, и выполнение ваших тестов займет 45 минут (поверьте мне, я был там). Медленные тесты означают, что вы никогда не будете их запускать, а это значит, что они будут сломаны большую часть времени и бесполезны.

3) Ваше удаление не удастся из-за пропущенной связи или зависимости по внешнему ключу, после чего данные из корзины останутся в вашей базе данных. Эти данные из мусора приведут к сбою других тестов.

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

Answer 2

Я считаю, что лучше всего делать то, что вы обрисовали. Однако вместо того, чтобы разбивать событие создания на каждую операцию, я стремлюсь создать одну запись в одном методе, но сохраняю значение идентификатора этой записи в закрытой переменной класса, а затем извлекаю ее (считываю) внутри каждого метода. Итак, у меня есть метод Read assert, затем другой метод Update assert и, наконец, метод Delete assert.

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