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

Разве не было бы полезно писать тесты во время проверки кода человеком, который делает проверку, предполагая, что мы не делаем TDD?

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

Плюсы я нашел:

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

Минусы я нашел:

1. Цикл обратной связи между написанием кода и тестированием растет.

РЕДАКТИРОВАТЬ: Я знаю, что это не будет работать на "нормальных" веб-приложениях. Я имел в виду угловой случай, когда вы реализуете сложные научные алгоритмы, требующие тщательной проработки деталей. Давайте предположим что-то вроде реализации моей собственной библиотеки графов, NLP и т. Д. Интересно, если код, который мы пишем, изолирован от баз данных и такой, но очень сложный для понимания, не будет ли дополнительный уровень контроля, другой человек, которому нужно понять источник написать код и сделать значимый тест, сделать весь процесс менее подверженным тем менее очевидным ошибкам, которые не приводят к сбою приложения, но в конечном итоге делают ваши результаты мусором?

Разве не было бы полезно писать тесты во время проверки кода лицом, выполняющим проверку?

Я обнаружил, что хорошее время для написания тестов - это когда вы понимаете, что вам нужен тест для ситуации.

Переключение задач для компьютеров стоит дорого, а тем более для людей.

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

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

Предполагая, что мы не делаем TDD?

Даже если вы практикуете TDD, если вы понимаете, что вам нужен тест во время проверки кода, такого, которого у вас нет, почему бы не написать тест тогда и там?

Pros

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

Действительно ли это обман, что больше тестов может привести к большему количеству кода? Если тест был необходим, и код был необходим для теста, и теперь он у вас есть, то это хорошо .

Предостережения

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

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

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

Это все победы в моей книге.

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

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

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

Я согласен с ответом @ RobbieDee, но мне нужно добавить еще немного.

Если вам действительно нравится эта идея, почему бы не дать тем же людям писать тесты перед кодом в качестве исполняемых критериев приемлемости для пользовательской истории?

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

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

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

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

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

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

Как вы говорите, если вы работаете в команде TDD, это спорный вопрос, поскольку код уже должен быть протестирован.

В целом, я не думаю, что это отличная идея, но это зависит от вашего текущего подхода и того, что работает для вас. По сути, проблема, которую я вижу, заключается в том, что вы теряете преимущество «короткой обратной связи» тестов. Получение мгновенного уведомления в тот момент, когда вы что-то ломаете, даже когда вы пишете новый код, - это то, где тесты действительно блестят Если вы откладываете тестирование до проверки кода, вы в основном говорите: «Мы могли бы решить эту проблему раньше, за меньшее время и с меньшим количеством вовлеченных людей, но, по крайней мере, мы все что-то узнали (возможно)». Я предпочел бы просто убедиться, что люди отправляют проверенный код на проверку, а затем вы оцениваете правильность и ремонтопригодность тестов. В конце концов, проверка кода предназначена для проверки, а не для написания кода.

С другой стороны, я рекомендую вам поиграться с тестами / кодом во время обзора. Попробуй что-нибудь сломать. Закомментируйте условие if. замените логическое значение литералом true / false. Посмотрите, не проходят ли тесты.

Но да, в общем, я рекомендую вам написать свои тесты вместе с вашим кодом, а затем пересмотреть все сразу.

Это зависит от того, что вы делаете в обзоре кода. Я думаю, что есть две основные причины для написания тестов на этом этапе:

• Во-первых, если вы также проводите рефакторинг во время проверки кода и отмечаете, что недостаточно модульных тестов, чтобы охватить тот тип рефакторинга, который вы хотите применить, добавьте такие тесты.

• во-вторых, если код выглядит так, как будто в нем есть ошибка, и вы хотите, чтобы он это доказал (или опроверг), напишите тест для него

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

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

Нет, не делай этого. Вы заставите их думать, что TDD ужасен.

Я думаю, что @ k3b имеет это право в комментариях к вопросу. Код, написанный с помощью процесса в стиле TDD, имеет тенденцию выглядеть и взаимодействовать совершенно иначе, чем код, написанный без тестов. Добавление (хороших) тестов в непроверенный код обычно требует большого количества рефакторинга кода для выяснения его намерений и движущихся частей.

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

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

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

Модульные тесты во время проверки кода являются плохой заменой модульных тестов во время разработки.

То, что вы предлагаете, интуитивно понятно. Для чего нужен обзор? Чтобы проверить, что код хороший. Для чего нужны тесты? Чтобы проверить, что код хороший. Так почему бы не объединить два?

Вот почему

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

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

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

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

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

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

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

Даже рецензент будет гораздо лучше понимать систему, если ей нужно будет пройти тщательные тесты кода , а затем, если ей нужно будет решить для себя, когда она может прекратить писать углубленный тест и просто ОК проверки кода.

Если разработчик не пишет модульные тесты, рецензент тоже не будет. Есть много препятствий для принятия тестирования в качестве обычной практики. Может быть, вы находитесь под слишком большим давлением, и вашу кодовую базу сложно проверить. Возможно, вы не настолько опытны в тестировании и чувствуете, что не можете позволить себе обучение. Может быть, у вас есть убийца топора, отправляющий заметки с угрозами людям, которые пишут тесты. Я не знаю!

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

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

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

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

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