Что должно быть на первом месте: тестирование или проверка кода?

Я довольно новичок в программировании шаблонов проектирования и жизненных циклов, и мне было интересно, что должно быть на первом месте, проверка кода или тестирование, относительно того, что это делается отдельными людьми?

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

Какой подход рекомендуется и почему?

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

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

В идеале в Agile мире оба :)

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

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

Проверка кода выполняется для «полировки» того, что уже работает, чтобы гарантировать, что код имеет желаемый уровень качества и соответствует руководящим принципам, определенным компанией.

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

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

Проверьте сначала. Тест последний. Тест, тест, тест.

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

Тестирование очень понятно: либо оно работает, либо не работает. Так что тестируйте, тестируйте, тестируйте! И пересмотр кода, если это возможно.

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

Затем у нас были обзоры единицы. Как правило, это делалось с тремя разработчиками, и было бы сделано, когда модуль / функция была протестирована и была готова для объединения в основное дерево. Это был самый мрачный обзор, и в нем было бы много подробностей. У нас было три разработчика для этого, потому что у нас был первоначальный автор кода, сопровождающий дерева, который должен был подписать код, прежде чем он мог быть объединен, и третий разработчик, который был выбран в качестве резервной копии для первоначального разработчика. (Идея состоит в том, что после того, как часть кода была закончена, должна быть полная передача знаний еще одному члену команды, поэтому в команде всегда должно было быть как минимум 2 человека, которые были полностью довольны любой частью базы кода).

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

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

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

Что первым, яйцо или курица?
Это зависит.

Если вы новичок и не уверены в том, что делаете, то непременно попросите сверстника помочь вам. Это неофициальный, но очень серьезный и ценный обзор кода.

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

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

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

Только мои два цента.

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

• Проектные проверки
• Проверка кода
• Модульные тесты
• Новые функциональные тесты
• Регрессионные тесты
• Тесты производительности
• Системные тесты
• Внешние бета-тесты

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