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

10

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

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

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

language-agnostic code-reviews

— dimba
источник

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

— Ллойд Пауэлл

20

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

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

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

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

— Брайан Андерсон
источник

11

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

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

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

— Нил Томпсон
источник

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

— Димба

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

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

— Димба

Привет Димба. Я не уверен, что есть абсолютный лучший способ быть честным. Лично у меня будет проверка кода после написания тестов, но это потому, что я знаю себя и предпочтения людей, с которыми я работаю. Может быть, попробовать каждую технику и посмотреть, какой вы / ваша команда предпочитаете? Главное, у вас есть тесты - так хорошо сделано там.

4

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

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

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

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

— Скотт Коутс
источник

2

Хорошо,

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

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

А ТАКЖЕ

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

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

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

@Спасибо за ответ. Может быть, я не совсем понял, но я не рассматриваю проверку кода как своего рода формальные ворота «контроля качества». Я пытаюсь понять, что является «правильным» способом с точки зрения скорости / качества разработки

— димба

2

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

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

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

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

— Armel
источник