Модульные тесты во время проверки кода являются плохой заменой модульных тестов во время разработки.
То, что вы предлагаете, интуитивно понятно. Для чего нужен обзор? Чтобы проверить, что код хороший. Для чего нужны тесты? Чтобы проверить, что код хороший. Так почему бы не объединить два?
Вот почему
Внедрение тестируемого кода - тяжелая работа. Написание кода, который работает только с одной вещью, для которой он предназначен, - это одна вещь; Написание кода, который может быть эффективно и действенно протестирован, - это другое. Тот факт, что код теперь выполняется в двух сценариях - «реальная работа» и «тестирование» - требует гораздо большей гибкости, требует, чтобы этот код был способен существенным образом существовать самостоятельно.
Написание кода, чтобы его можно было тестировать, - это дополнительная работа и умение. Реорганизация чужого кода для тестируемости, когда он изначально не был написан с учетом тестируемости, может быть серьезной задачей.
Вы дублируете усилия между разработчиком и рецензентом. Предположительно, ваш разработчик не передает свой код на проверку без, по крайней мере, некоторого уровня уверенности, что он работает. Ему уже нужно проверить код. Сейчас существуют разные уровни и сферы тестирования. QA тестирует код после разработчика и рецензента. Но независимо от того, какой объем вы считаете подходящим для разработчика и рецензента, для разработчика не имеет смысла выяснять, как один раз протестировать код до этого уровня , но сделать свои тесты одноразовыми и трудными для воспроизведения, а затем привлечь рецензента к разработать тест сноваНа этот раз они автоматизированы и воспроизводимы. Вы просто иметь обе из них тратить время на написание те же тесты - один раз плохо, когда хорошо.
Вы превращаете обзор в гораздо более длинный и трудоемкий шаг. Если тестирование является основной частью процесса проверки, что произойдет, если некоторые тесты не пройдут ? Отвечает ли рецензент за выполнение всех тестов, поэтому ему также необходимо отладить код? Или это будет пинг-понг взад-вперед, один написание тестов, другой заставит их пройти?
Иногда вы можете написать целую кучу тестов, которые все ортогональны друг другу, поэтому вам не нужно пинг-понг. Рецензент пишет дюжину тестов, половина из них не проходит, разработчик исправляет ошибки, и все тесты остаются в силе и проходят сейчас. Но ... в большинстве случаев у вас есть ошибки блокировщика, или ошибки, которые требуют редизайна и изменений API, или еще чего-нибудь. Если вы перекладываете ответственность за прохождение тестов между рецензентом и разработчиком, то на самом деле вы не находитесь на стадии рецензирования. Вы все еще развиваетесь.
Необходимость написания тестов не стимулирует более тщательный анализ. По сути, это означает, что чем глубже вы идете, тем больше тестов вам нужно написать, и, вероятно, это будут сложные тесты, которые должны углубляться в систему.
Сравните с разработчиком, пишущим тесты, где его стимул: если я не пишу важные тесты, рецензент укажет это в обзоре.
Даже рецензент будет гораздо лучше понимать систему, если ей нужно будет пройти тщательные тесты кода , а затем, если ей нужно будет решить для себя, когда она может прекратить писать углубленный тест и просто ОК проверки кода.
Если разработчик не пишет модульные тесты, рецензент тоже не будет. Есть много препятствий для принятия тестирования в качестве обычной практики. Может быть, вы находитесь под слишком большим давлением, и вашу кодовую базу сложно проверить. Возможно, вы не настолько опытны в тестировании и чувствуете, что не можете позволить себе обучение. Может быть, у вас есть убийца топора, отправляющий заметки с угрозами людям, которые пишут тесты. Я не знаю!
Но какова бы ни была причина, можно с уверенностью сказать, что это в равной степени относится и к рецензенту, и к разработчику. Если команда испытывает стресс, у рецензента не остается больше времени, чем у разработчика (если она делает это, перераспределяйте работу, чтобы люди не испытывали такого стресса ). Если никто не знает, как правильно писать модульные тесты, рецензент, вероятно, тоже не знает (если она это делает, она должна сесть и научить своих товарищей по команде ).
Это предложение звучит как попытка переложить деньги с одного коллеги на другого. И я просто не вижу способа, чтобы это сработало хорошо, в первую очередь, потому что очень трудно (и вредно для здоровья) создать ситуацию, когда один человек может проводить тестирование, а другой - нет. любое тестирование вообще.
Что делает работу является имея тесты обзор крышки , а также. Если разработчик уже написал десять тестов, гораздо более вероятно, что рецензент может помочь предложить еще десять тестов, чем если бы разработчик не написал ни одного.
И, если тестирование угловых случаев является серьезной задачей, возможно, имеет смысл распределить это более широко по всей команде. ** Как только код тестируется в первую очередь, написание большего количества тестов становится намного проще. **
Обзор - прекрасное время для выявления угловых случаев. И, если рецензент может вскочить и написать тест для угловых случаев, которые она находит, то эй - тем лучше! Но, вообще говоря, предполагая, что рецензент может написать тесты, в которых разработчик не звучит как очень плохая идея.