С какого юнит-теста вы бы начали?

Question

Когда вы придумали общий дизайн / идею о том, как должна работать часть системы, как вы решаете, с чего начать при выполнении TDD, или, скорее, как вы решаете начать свой первый тест?

Answer 1

Давайте предположим, что я пишу класс под названием Oven, чтобы испечь мои восхитительные Pie объекты. Вот так я прохожу заказ на юнит-тест:

1. Что мне нужно сделать, чтобы создать экземпляр объекта? В этом случае, скорее всего, это будет Oven oven = new Oven(); Нет теста для этого, я полагаю.
2. Как мне подготовить объект к использованию? oven.turnOn(int degrees) звучит хорошо, я сделаю это. Как мне это проверить? Лучше сделай oven.getTemperature(). Там очевидный тест.
3. Хорошо, духовка уже достаточно горячая, и я хочу испечь свой Pie. Для этого мне нужно oven.bake(Pie p), поэтому я сделаю это. Но что теперь? Я хочу проверить, готов ли пирог, но вместо того, чтобы иметь oven.isPieReady(), я думаю, что oven.pastryStatus(), который возвращает такие вещи, как «ничего в духовке», «сырые», «почти готовые», «приготовленные» и «обугленные», звучит хорошо и вообще должен быть более расширяемым, чем oven.isPieReady(), поэтому я сделаю это.

И так далее, и тому подобное. Итак, я сделаю свои тесты для того, чтобы использовать объект, уточняющий спецификацию, когда я иду. В конце я обычно получаю довольно простой, но мощный API, который делает то, что я хочу. После того, как я проверил мой API на модульном уровне, я запустил покрытие своего кода, чтобы увидеть, что я пропустил, а затем добавил дополнительные тесты для них.

Answer 2

Я уже некоторое время преподаю в классе по TDD, и многие участники начинают с тестирования всех ошибок. Как бы они ни были важны, это не лучший способ начать ИМО.

Начните с настройки тестов, которые легко внедрить, и при этом вы узнаете, движетесь ли вы в правильном направлении в отношении функций, которые вы пытаетесь реализовать. Поэтому, если вы строите стек, убедитесь, что вы проверяете push и pop перед тестированием ошибок.

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

Хорошая идея - выполнить каждый тест в обратном порядке. Итак, начните с написания утверждения Assert. Это цель проверки для этого теста. Затем добавьте все необходимые шаги, чтобы добраться до точки, где вы можете делать то, что делает Assert.

Answer 3

Столкнувшись со списком тестов для реализации, вы получите категории

1. Тривиально для тестирования, но вы уверены, что вы может сделать это
2. Нетривиально, но вы достаточно уверены в сделать это.
3. Нетривиально, но трудно-абсолютно без понятия сделать это.

В таком сценарии выберите один из корзины категории 2, потому что он обеспечит максимальное количество знаний / обучения на единицу затраченного времени. Кроме того, это даст вам уверенность и повысит уверенность, чтобы перейти к более сложным тестам категории 3.

Кажется, я получил это от TDD By Example - Кент Бек. Посмотрите, если у вас есть время. Рекомендуем.

Answer 4

Это общие рекомендации, которые я считаю полезными для определения приоритетов юнит-тестирования:

1) Определение пограничных объектов (Win / WebForms, CustomControls и т. Д.).

2) Идентифицировать объекты управления (объекты бизнес-уровня)

3) Записывать модульные тесты только для открытых объектов управления методами, вызываемыми граничными объектами. Таким образом, вы будете уверены, что освещаете основные функциональные аспекты своего приложения.

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

Answer 5

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