Как вы адаптировали свои юнит-тесты к изменяющимся требованиям?

Question

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

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

Answer 1

По определению модульные тесты не повторяют требований для приложения. Они описывают требования к модулю. Разница в том, что модуль можно использовать повторно даже в приложении с другими требованиями или вообще не использовать. Таким образом, изменяющиеся требования не влияют на реальные юнит-тесты (за исключением того, что вы должны писать новые для новых модулей или отказываться от старых тестов для модулей, которые больше не нужны для измененных требований).

С другой стороны: приемочные испытания имеют дело с требованиями на уровне приложений. Поэтому я думаю, что вы говорите о приемочных тестах.

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

Answer 2

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

Answer 3

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

Есть какая-то конкретная причина, почему вы так думаете? Я чувствую некоторый страх, или он просто «не ломай его, когда он работает»

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

• убедитесь, что рабочая версия была проверена.
• Повторите шаг 1 только для уверенности.
• сканировать ваш набор тестов. Найдите те, которые вам нужно вывезти. Найдите те, которые нужно изменить. Найдите новые тесты, которые вам нужно понять. Используйте чистый лист бумаги, чтобы делать заметки
• Теперь выполняйте один тест за раз. Если вы не следовали принципу «СУХОЙ» и «Один раз и только один раз», любые изменения, которые вам нужно внести, должны быть в одном месте. Если нет, то вы должны были сделать рефакторинг раньше ... но еще не слишком поздно .. перед внесением изменений извлеките код в одно место
• Повторите предыдущий шаг до завершения

Answer 4

По сути, я перевожу требования в тесты, которые проверяют соответствие кода требованиям

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

Или они тестируют что-то, что не соответствует требованиям заказчика.

Как сообщается, Джон Мейнард Кейнс сказал: «Когда факты меняются, я меняю свое мнение. Что вы делаете, сэр?»

Я думаю, что здесь сложилась аналогичная ситуация. Ваши факты были изменены для вас

Answer 5

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

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

Затем измените ваш исходный код так, чтобы переписанные тесты теперь проходили.

Answer 6

У меня есть два ответа на ваш вопрос, один философский, а другой тактический.

На философском фронте важно рассматривать ваши юнит-тесты как код. Это означает, что все нормальные черты хорошего кода обычно подходят для хороших тестов: выявление намерений, удаление дублирования и т. Д. Многие, возможно, большинство сбоев, которые я видел при модульном тестировании, произошли потому, что люди не обработали свои тесты таким образом, но вместо того, чтобы просто закодировать их и никогда не пересматривать их, чтобы увидеть, следует ли их реорганизовать.

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

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

1. Тест, который фактически проверяет это поведение
2. Места, в которых это поведение используется в общем коде приборов

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