Модульное и интеграционное тестирование: как это может стать рефлексом

Все программисты в моей команде знакомы с модульным тестированием и интеграционным тестированием. Мы все с этим работали. У нас есть все письменные тесты с ним. Некоторые из нас даже почувствовали улучшение доверия к своему собственному коду.

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

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

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

Мой вопрос заключается в следующем: существуют ли какие-либо методы, с которыми вы экспериментировали, которые помогают создать динамику / импульс внутри команды, что приводит к тому, что люди, естественно, хотят создавать и поддерживать эти тесты?

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

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

Сделайте тесты самостоятельно. Заметно ругайте себя, когда вы их не делаете. Укажите, где «хороший» программист поймал бы эту ошибку, если бы написал модульные тесты. Никто не хочет быть плохим. Сделайте так, чтобы это нежелательное поведение было плохим, и люди будут следовать.

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

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

Лично для меня это было просто открытие инфраструктуры StoryQ для BDD в DotNet, которая слишком легко игнорировала, и заставила меня полностью преодолеть «барьер» тест-первый-тест-одновременно. Позже я подтвердил свой выбор, когда нашел NCrunch для Visual Studio. Иногда залог успеха заключается не в продаже идеи, а в простом снижении усилий, необходимых для внесения радикальных изменений в привычки ... и даже тогда это может занять немного времени и работы. Однако этих же личных триггеров было недостаточно, чтобы повлиять на подход моих коллег в то время, которые все еще пишут столько же тестового кода одновременно или даже после кода реализации.

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

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

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

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

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

По моему опыту, тест-первый (стиль TDD) - это то, к чему вы можете быстро привыкнуть, потому что есть как минимум 2 непосредственных, ощутимых, высвобождающих эндорфин преимущества:

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

• Цикл TDD перемежается частыми моментами «зеленой полосы», где вы можете насладиться вкусом немедленного успеха. Это постоянно держит ваш разум довольным и готовым перейти к следующей функции для реализации.

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

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

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

чем более неловко что-то делать, тем менее вероятно, что вы выработаете у него привычку

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

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

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

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

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

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

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