Должен ли анализ кода выполняться до или после юнит-тестов

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

Некоторые факторы, которые мы, возможно, должны принять во внимание (может быть больше):

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

Вы должны всегда тестировать модуль перед выполнением обзора кода и вот почему

1. Если ваш код сломан таким образом, что его поймают модульные тесты, вы будете тратить время другого разработчика, вовлекая их в цикл красный / зеленый / рефакторинг.
2. Тесты показывают другим разработчикам предполагаемое использование кода, что облегчает просмотр.
3. Тесты должны быть рассмотрены вместе с кодом, который тестируется в случае, если вы пропустили тестовые случаи или ваши тесты не работают должным образом.
4. Тесты и проверка кода, как правило, обнаруживают разные проблемы с небольшим совпадением обнаруженных проблем. Модульные тесты не раздражают необходимость повторного тестирования кода, когда рецензент обнаруживает проблемы, разработчики раздражаются и, вероятно, не будут делать это во второй раз.

Возможно, есть и другие причины, но это те, которые я лично видел и испытал, внедрив методы проверки кода в 3 разных командах / компаниях.

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

Обзоры кода для того, когда код "готов".

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

Кроме того, тесты нуждаются в проверке и рефакторинге, поэтому имеет смысл, что они являются частью проверки кода.

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

Убедитесь, что тесты также рассмотрены. Это очень важно для тех, кто плохо знаком с юнит-тестами.

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

Вам не нужно реализовывать вышеупомянутые темы, но вы должны понимать их.

Хорошо,

Это зависит от того, что вы подразумеваете под «модульным тестом» ...

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

А ТАКЖЕ

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

Но ведь лично для просмотра кода, после или после юнит-теста это не реальный критерий для меня ...

Почему мы делаем codereview? Для качества кода ... Вместо «контроля качества» внедрите качество в свою среду разработки программного обеспечения…

Я бы сказал, давайте будем «проворны» ... не ждите, пока код будет закончен, чтобы сделать быстрый неформальный обзор кода: есть разработчики, с которыми и субъекты, с которыми вы действительно можете ждать всего код + тестовый этап должен быть закончен ... но

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

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

и, кстати, модульные тесты также нуждаются в пересмотре кода.