Вы проверяете модульные тесты кода?

Ответ 1

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

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

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

Я бы порекомендовал пару-программирование между одним разработчиком с опытом unit test и новичком, а затем просмотрел это, когда рецензент кода был третьим человеком.

Ответ 2

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

Ответ 3

Да. Это быстро. Тест должен быть очевиден; если это не так, у вас нет надежного тестового примера.

Один из членов команды переутомлялся (он тестировал тестовые данные для других модульных тестов.)

Это способ проверить покрытие, стиль и общую правильность.

Кроме того, дефекты unit test не так серьезны, как дефекты рабочего кода. Если есть проблемы стиля, вам больше не нужно обсуждать достоинства пробелов вокруг (). Вы просто говорите: "У этого есть проблемы стиля на строках 43, 87, 96, но мы все равно его совершаем".

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

Ответ 4

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

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

Ответ 5

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

Ответ 6

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

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

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

Один из способов просмотра всего кода unit test, а также всего производственного кода Pair Programming, хотя трудно получить как управление, так и разработчики.

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

Ответ 7

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

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