Как Вы адаптировали свои модульные тесты для контакта с изменяющимися требованиями?
Вы можете проверить, не является ли slug пустым, перед рендерингом ссылки маршрутизатора, как показано ниже:
<router-link v-if="project.slug" to="{ name: 'projects.show', params: { slug: project.slug }}">
<h4>{{ project.title}}</h4>
</router-link>
Но я уверен, почему slug пуст.
6 ответов
Так как бывшие требования так полностью кодируются в существующих модульных тестах, кажется, что изменение их для приспосабливания новым требованиям пригласило бы аварию.
Какая-либо определенная причина, почему Вы думали бы так? Я обнаруживаю некоторый страх, или это просто, 'не повреждают его когда его работа'
Изменение происходит. В этом случае это означает больше денег рабочего времени. Если бизнес не имеет никакой проблемы с ним, ни если Вы (если расписание не негуманно:). Если спецификация изменилась,
- удостоверьтесь, что в рабочей версии зарегистрировались.
- Повторите шаг 1 только, чтобы быть уверенными.
- просканируйте свой набор тестов. Найдите, которые необходимо вынуть. Найдите, которые должны измениться. Найдите новые тесты, которые необходимо понять. Используйте пустой лист бумаги, чтобы сделать заметки
- Теперь продолжите двигаться один тест за один раз.. Если Вы не следовали за DRY / Однажды и только однажды принцип, любые изменения, которые необходимо внести, должны быть в одном месте. В противном случае необходимо было осуществить рефакторинг ранее.. но не слишком поздно.. извлеките код в единственное место прежде, чем внести изменение
- Повторите предыдущий шаг, пока не сделано
На определение модульные тесты не копируют требования для приложения. Они описывают требования для модуля. Вот в чем разница, модуль может быть снова использован даже в приложении с различными требованиями или не используется вообще. Таким образом, изменяющиеся требования не влияют на реальные модульные тесты (за исключением того, что необходимо записать новый для новых модулей или отказаться от старых тестов для модулей, больше не необходимых для измененных требований).
С другой стороны: приемочные испытания имеют дело с требованиями к прикладному уровню. Таким образом, я думаю, что Вы говорите о приемочных испытаниях.
Я добавил бы новые требования как новое приемочное испытание. Но для старых необходимо просмотреть их, как они делаются недействительным измененными требованиями.
Я добавил бы новые тесты и заставил бы их передать. Затем Вы смотрите на то, какие тесты были повреждены в результате. Если Вы полагаете, что старые тесты в противоречии с новыми тестами затем, Вам, вероятно, придется удалить старые тесты. Иначе Вы изменяете код для создания старой тестовой передачи также.
Если ваши юнит-тесты больше не соответствуют требованиям, тогда они не должно быть там - в конце концов - все, что они теперь говорят вам, это то, что ваш код соответствует требованиям, которых больше не существует!
Всякий раз, когда у вас есть изменение требований, вы должны изменять тесты, которые представляют измененные требования, и проверять, что тест сейчас fail (если раньше они все прошли, верно?;))
Затем измените ваш исходный код, чтобы переписанные тесты теперь проходили.
В сущности я перевожу требования в тесты, которые проверяют, что код соответствует требованиям
В то время как я соглашаюсь с ответом Mnementh, это, мне, является ключевым комментарием. Если тесты являются переведенной версией требований, то, если требования изменились, тесты должны измениться.
Или они тестируют на что-то, что не отвечает требованиям клиента.
Поскольку John Maynard Keynes, как сообщают, сказал, "Когда факты изменяются, я изменяю свое мнение. Что Вы делаете, сэр?"
Я думаю, что здесь существует analagous ситуация. Ваши факты были изменены для Вас
У меня есть два ответа на Ваш вопрос, один философский и другое тактическое.
На философской передней стороне важно рассмотреть Ваши модульные тесты как код. Это означает, что все нормальные черты хорошего кода обычно подходят для хороших тестов: раскрытие намерения, удалите дублирование и т.д. Многие, возможно, большинство, отказов, которые я видел с поблочным тестированием, прибыло, потому что люди не рассматривали свои тесты этот путь, а скорее, чем просто кодированный их и никогда не пересматривали их, чтобы видеть, должны ли они быть пересмотрены.
По моему опыту, если Вы достигли точки, где Ваши модульные тесты являются помехой для изменения, это - потому что у Вас есть технический долг в Ваших тестах.
Таким образом, мое тактическое предложение то, что, прежде чем Вы попытаетесь изменить свои требования, Вы надеетесь осуществлять рефакторинг Вас тесты. Каждый тест должен иметь уникальную причину передать/привести к сбою, и поведение за пределами этого должно быть в общем коде. Это означает, что для любого данного поведения изменяются, у Вас будет два места для изменения тестов:
- Тест, который на самом деле проверяет то поведение
- Места, что поведение используется в общем коде приспособления
Вы могли бы найти эту статью полезной: Вырастите Свой Ремень безопасности Естественно. Это было действительно о допускающей повторное использование тестовой обвязке для функционального тестирования, но я нахожу идеи очень полезными в моих модульных тестах также.