«Нулевая итерация» - сквозной приемочный тест в простой форме обратной связи - PullRequest
Новая
       16

«Нулевая итерация» - сквозной приемочный тест в простой форме обратной связи

7 голосов
/ 26 сентября 2010

Я читал «Растущее объектно-ориентированное программное обеспечение, руководствуясь тестами» в последнее время.Авторам этой книги предлагается всегда начинать разработку функции с сквозного приемочного испытания ( до запуска цикла TDD), чтобы не потерять трек прогресса и убедиться, что вы все еще находитесь ната же страница во время модульного тестирования.

Хорошо, поэтому я начал писать очень простое приложение на python + django, чтобы попробовать этот подход.Я хочу, чтобы пользователь мог задать вопрос через контактную форму, после чего вопрос должен быть сохранен в БД, и после завершения должен быть отправлен сигнал для отправки уведомлению, который отправит последующее сообщение.

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

Любые примеры приветствуются.

Ответы [ 2 ]

1 голос
/ 27 сентября 2010

Вам не нужно вообще включать все возможности в приемочные тесты - вы все равно будете писать модульные тесты.Поэтому я бы сказал, что для начала достаточно одного теста: «пользователь может заполнить форму, сохранить ее и загрузить обратно».Затем вы можете добавить дополнительные тесты, если вы считаете, что определенный аспект вашей системы достаточно важен, чтобы он нуждался в приемочных тестах.Не беспокойтесь об использовании всех возможностей здесь, вы все равно будете писать тонны модульных тестов, где вы будете тестировать все!

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

0 голосов
/ 27 сентября 2010

Этот вариант использования приводит к нескольким тестам (каждый тестирует отдельный возможный путь выполнения).

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

Мои первые тесты будут:

  • Счастливый путь, 1-я часть frontend-form + уровень контроллера: пользователь передает правильные данные, контроллер принимает форму и регистрируется на консоли / стандартный вывод
  • Счастливый путь, 2-я часть: вместо входа в stdout все хранится в базе данных
  • Счастливый путь 3-я часть: Последующее письмо отправляется и принимается Пользователем
  • Обработка ошибок валидации (пользователь неправильно заполняет форму, например, пропускает обязательные поля, неверный шаблон электронной почты)
  • ...

Заполните остальные;) Зависит от более подробных требований ...

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

...