Делай как вGoogle
 Скачать 5.77 Mb.
|
|
История тестирования в Google Теперь, когда мы обсудили подходы к тестированию в Google, будет полезно узнать, как мы пришли к ним. Как отмечалось выше, инженеры в Google не всегда осознавали ценность автоматического тестирования. На самом деле до 2005 года тестирование 1 Для каждого поддерживаемого языка программирования в Google есть один стандартный фреймворк тестирования и одна стандартная библиотека с заглушками и фиктивными объектами. Большинство тестов на всех языках для всей кодовой базы выполняет единая инфраструктура. История тестирования в Google 225 было очень редким явлением, а не организованной практикой. В большинстве случаев тестирование выполнялось вручную, если вообще выполнялось. Однако с 2005 по 2006 год произошла революция в тестировании, изменившая наш подход к разработке ПО. Ее последствия продолжают ощущаться в компании и по сей день. Катализатором послужил опыт проекта GWS, который мы обсудили в начале главы. Он показал, насколько мощным может быть автоматизированное тестиро- вание. После усовершенствования проекта GWS в 2005 году наработанные приемы и практики стали распространяться по всей компании. Инструменты, использовав- шиеся в ту пору, были довольно примитивными. Однако нашлись добровольцы, объединившиеся в группу Testing Grouplet, которые активно взялись за развитие этих инструментов. Внедрить идею автоматизированного тестирования в сознание компании помогли три ключевые инициативы: программы ранней ориентации и сертификации прак- тики тестирования, а также новостная рассылка «Тестирование в туалете». Каждая оказывала свое влияние, и вместе они изменили инженерную культуру Google. Программа ранней ориентации Несмотря на то что многие инженеры избегали тестирования, пионеры автоматизи- рованного тестирования в Google понимали, что, учитывая темпы роста компании, число новых инженеров быстро превысит число существующих членов команд. И если им удастся привлечь всех новых сотрудников к тестированию, они сумеют изменить культуру. К счастью, в компании существовал и продолжает существовать важный этап, через который проходят все новые инженерные кадры: ориентация. Программы ранней ориентации в Google в основном касались таких вопросов, как медицинские льготы и особенности работы Google Search, но начиная с 2005 года в них была включена часовая лекция, рассказывающая о значимости автоматизированного тестирования. 1 В ходе лекции обсуждались различные преимущества тестирования, такие как увеличение продуктивности инженера и качества документации, а также улучшение поддержки рефакторинга. Еще в лекции рассказывалось, как написать хороший тест. Для многих нуглеров того периода эта лекция была первым знаком- ством с тестированием. Но самое главное, что все идеи представлялись в ней так, будто они были стандартной практикой, принятой в компании. Новые сотрудники не знали, что их используют в роли троянских коней с целью внедрить эту идею в ничего не подозревающие команды. Попадая в свои команды после ориентации, нуглеры начинали писать тесты и за- давать вопросы тем, кто тесты не писал. Уже через год-два численность инженеров, обученных тестированию, превзошла общую численность инженеров дотестовой эпохи и многие новые проекты получили правильный старт. 1 Эта лекция оказалась настолько успешной, что обновленная ее версия проводится до сих пор. На самом деле это одна из самых долгоживущих лекций в программе ориентации. 226 Глава 11. Основы тестирования В настоящее время тестирование широко распространено в отрасли, поэтому боль- шинство новых сотрудников приходят в компанию, уже ожидая встретиться с усто- явшейся практикой автоматизированного тестирования. В нынешней программе ориентации проводится лекция, укрепляющая ожидания в отношении тестирования и связывающая знания нуглеров о тестировании, полученные за пределами Google, с проблемами, обусловленными большим размером и высокой сложностью нашей кодовой базы. Программа сертификации практики тестирования Первоначально большие и наиболее сложные разделы нашей кодовой базы оказались малопригодными для применения передовых практик тестирования. Некоторые проекты имели настолько низкое качество кода, что протестировать их было прак- тически невозможно. Чтобы ясно обозначить цель для проектов, группа Testing Grouplet разработала программу сертификации практики тестирования, которую они назвали «Test Certified». Цель этой программы — дать командам возможность осознать уровень зрелости своих процессов тестирования и, что особенно важно, предоставить рецепты по их улучшению. Программа была разбита на пять уровней, каждый из которых требовал от команды выполнить определенные действия по совершенствованию практики тестирования. Уровни были определены так, чтобы каждый шаг можно было выполнить в течение квартала, что хорошо укладывалось во внутреннюю систему планирования в Google. Первый уровень программы охватывал основы: организацию непрерывной сборки, внедрение оценки охвата тестирования, классификацию всех тестов на маленькие, средние или большие, выявление (без обязательного исправления) нестабильных тестов и создание набора быстрых (необязательно всеобъемлющих) тестов, которые можно часто запускать. На каждом последующем уровне добавлялись новые задачи, такие как «отказ от выпуска новых версий при наличии сломанных тестов» или «удаление всех недетерминированных тестов». Пятый уровень требовал автомати- зации всех тестов, выполнения всех быстрых тестов перед каждой фиксацией кода в репозитории, отсутствия недетерминированных тестов и охвата тестами каждого поведения. Внутренняя информационная панель, показывающая уровень каждой команды, оказывала сильное социальное давление. Вскоре команды начали сорев- новаться друг с другом, стремясь подняться на более высокий уровень. К тому времени, когда программу «Test Certified» заменил автоматизированный подход, внедренный в 2015 году (подробнее об инструменте pH рассказывается ниже), она помогла повысить культуру тестирования более чем в полутора тысячах проектов. Рассылка «Тестирование в туалете» Из всех методов, использованных группой Testing Grouplet для совершенствова- ния практики тестирования в Google, наиболее оригинальным оказалась рассылка История тестирования в Google 227 «Тестирование в туалете» (TotT). Рассылка TotT имела простую цель: активно пропагандировать тестирование во всей компании. Вопрос в том, как лучше всего организовать пропаганду в компании, сотрудники которой разбросаны по всему миру. Группа Testing Grouplet рассматривала идею регулярной рассылки по электронной почте, но, учитывая, что сотрудники Google и без того перегружены электронной почтой, эти письма могли затеряться. После небольшого мозгового штурма кто-то в шутку предложил вывешивать листовки в туалетных кабинках. Мы быстро осознали гениальность этой идеи: туалетная кабинка — это место, которое каждый посещает хотя бы раз в день, несмотря ни на что. Как бы то ни было, идея была достаточно дешевой в реализации. В апреле 2006 года в туалетных кабинках в Google появилась короткая статья о том, как улучшить тестирование кода на Python, написанная небольшой группой добро- вольцев. Сказать, что реакция была самой разной, — ничего не сказать. Некоторые даже рассматривали это как вторжение в личное пространство и решительно возра- жали. Списки рассылки заполнились жалобами, но создатели TotT были довольны: даже те, кто жаловался, так или иначе, говорили о тестировании. В конечном итоге шум утих и рассылка TotT быстро стала частью культуры Google. К настоящему времени инженеры со всей компании опубликовали в рамках этой рассылки несколько сотен статей, охватывающих почти все мыслимые аспекты тестирования (в дополнение к множеству других технических тем). Многие с нетер- пением ждут новых листовок, а некоторые инженеры даже добровольно расклеивают листовки в разных помещениях. Мы намеренно ограничиваем размер каждой статьи ровно одной страницей, предлагая авторам сосредоточиться на наиболее важных и действенных советах. В хорошей статье должны описываться инструменты, которые инженер сможет немедленно попробовать. По иронии судьбы, статьи TotT, появляющиеся в одном из наиболее уединенных мест, оказали огромное общественное влияние. Большинство сторонних посетителей в какой-то момент видят эти статьи, что часто приводит к забавным разговорам о том, что гуглеры постоянно думают только о коде. Кроме того, статьи TotT пользуются большим успехом в блогах, что воодушевило оригинальных авторов. Они начали публиковать их отредактированные версии ( https://oreil.ly/86Nho ), делясь нашим опытом со всей отраслью. Несмотря на то что рассылка TotT начиналась как шутка, она пережила испытание временем и оказала самое большое влияние среди всех инициатив по тестированию, запущенных группой Testing Grouplet. Современная культура тестирования Современная культура тестирования в Google прошла долгий путь с 2005 года. Ну- глеры по-прежнему посещают лекции по тестированию в рамках программы ранней ориентации, и почти каждую неделю публикуются новые статьи TotT. Благодаря 228 Глава 11. Основы тестирования всему этому практика тестирования глубоко укоренилась в повседневном рабочем процессе разработчиков. Каждое изменение кода в Google должно пройти процедуру обзора, причем каждое изменение должно включать не только код, но и соответствующий тест. Ожидается, что рецензенты оценят качество и правильность обоих. Разумной мерой считается заблокировать изменение, если в нем отсутствуют тесты. В качестве замены программы сертификации практики тестирования одна из на- ших команд, занимающаяся вопросами увеличения продуктивности инженеров, недавно выпустила инструмент под названием Project Health (pH). Этот инстру- мент постоянно собирает десятки показателей о состоянии проекта, включая охват тестирования и задержку на выполнение тестов, и публикует эти сведения для внутреннего использования. pH измеряет состояние проекта по шкале от од- ного (худшее) до пяти (лучшее). Проект pH-1 считается проблемой для команды. Почти каждая команда, организовавшая непрерывную сборку, автоматически получает свою оценку pH. Со временем практика тестирования стало неотъемлемой частью культуры Google. У нас есть множество способов повысить ценность тестов для инженеров. Комби- нируя курсы обучения, методы мягкой мотивации, наставничество и даже элементы дружеского соревнования, мы укоренили в сотрудниках ясное осознание, что тести- рование касается каждого. Почему мы не требуем обязательного написания тестов? Группа Testing Grouplet хотела обратиться к высшему руководству с предложением о введении обязательного тестирования, но быстро отказалась от этой мысли. Любые требования о том, как разрабатывать код, даже из самых благих побуждений, будут серьезно противоречить культуре Google и, скорее всего, замедлят прогресс в раз- работке. Мы верим, что успешные идеи получат самое широкое распространение, нужно только доказать их успешность. Если инженеры сами решали начать писать тесты, это означает, что они полностью приняли идею тестирования и, вероятно, продолжат поступать правильно без вся- кого принуждения. Ограничения автоматизированного тестирования Не каждый тест следует автоматизировать. Например, тестирование качества результатов поиска предполагает человеческое суждение. Мы проводим целена- правленные внутренние исследования, привлекая экспертов, способных оценить качество поиска, которые выполняют запросы и записывают свои впечатления. Точно так же в автоматическом тестировании трудно уловить нюансы качества звука и видео, поэтому мы привлекаем людей для оценки качества систем телефонии или видеоконференций. Заключение 229 Также есть определенные творческие сферы, тестирование которых лучше всего проводят люди. Например, с поиском сложных уязвимостей в безопасности люди справляются намного лучше автоматизированных систем. Когда инженер обнаружит и поймет причину проблемы, он может добавить тест в автоматизированную систему тестирования, такую как Google Cloud Scanner ( https://oreil.ly/6_W_q ), где этот тест будет выполняться непрерывно и в большем масштабе. Этот принципиально творческий подход к тестированию имеет обобщенное на- звание — исследовательское тестирование. Человек рассматривает приложение как головоломку и решает ее, выполнив неожиданную последовательность шагов или передав неожиданные данные. При проведении исследовательского тестирования конкретные проблемы кода изначально неизвестны. Они обнаруживаются по- степенно, путем проверки часто упускаемых из виду путей выполнения кода или необычных ответов приложения. Так же как при поиске уязвимостей безопасности, для любой решенной головоломки инженер должен добавить автоматизированный тест, чтобы найденная проблема не повторилась в будущем. Автоматизированное тестирование понятного поведения кода позволяет сосредото- чить дорогостоящие усилия людей-тестировщиков на тех областях, где они могут принести наибольшую пользу, и избавить инженеров от рутины. Заключение Внедрение автоматизированного тестирования, управляемого разработчиками, ста- ла одной из самых эффективных практик программной инженерии в Google. Она позволила нам создавать большие системы большими командами быстрее, чем мы думали, и отвечать растущими темпами развития технологий. За последние 15 лет мы превратили тестирование в часть нашей инженерной культуры. За эти годы ком- пания выросла почти в 100 раз, и наша приверженность качеству и тестированию сегодня сильнее, чем когда-либо. Эта глава была написана с целью рассказать вам, как в Google относятся к тести- рованию. В следующих нескольких главах мы углубимся в некоторые ключевые темы, которые помогли нам сформировать представление о хороших, стабильных и надежных тестах. Мы подробно обсудим юнит-тестирование как наиболее широко используемый в Google вид тестирования. Поговорим об эффективном тестирова- нии взаимодействий с использованием дублеров, таких как имитации и заглушки, и исследуем проблемы, связанные с тестированием больших и сложных систем, подобных тем, которые мы имеем в Google. Прочитав следующие три главы, вы получите более полное и ясное представление о стратегиях тестирования, которые мы используем, и, что более важно, о причинах их использования. 230 Глава 11. Основы тестирования Итоги y Автоматическое тестирование образует основу для изменения ПО. y Автоматизация — необходимое условие масштабирования тестов. y Для поддержания достаточного охвата тестирования необходим сбалансирован- ный набор тестов. y «Если вам что-то понравилось, добавьте для него тест». y Для изменения культуры тестирования в организациях нужно время. ГЛАВА 12 Юнит-тестирование Автор: Эрик Кюфлер Редактор: Том Маншрек В предыдущей главе были представлены две основные оси классификации тестов в Google: размер и охват. Напомним, что под размером подразумевается объем ресурсов, потребляемых тестом, и число элементов инфраструктуры, вовлекаемых в тестирование, а под охватом — объем кода, проверяемого тестом. Размеры тестов четко определены в Google, чего нельзя сказать об уровнях охвата тестирования. Для обозначения тестов с относительно узкой областью охвата, такой как отдельный класс или метод, мы используем термин юнит-тест. Юнит-тесты обычно имеют маленькие размеры, но это не всегда так. После выявления ошибок второй наиболее важной целью тестирования является повышение продуктивности инженеров. По сравнению с более масштабными те- стами, юнит-тесты обладают множеством свойств, способствующих увеличению продуктивности. y Обычно это маленькие по размеру тесты — быстрые и детерминированные, что позволяет разработчикам часто запускать их и получать немедленную обратную связь. y Их, как правило, легко писать одновременно с кодом, который они тестируют, что дает инженерам возможность сконцентрировать свои тесты на коде, не на- страивая более крупную систему. y Простые в написании, они обеспечивают широкий охват тестирования, который дает инженерам дополнительную уверенность, что они ничего не нарушат, внося изменения. y Они позволяют быстро найти причину ошибки в случае неудачного тестового прогона благодаря своей простоте и нацеленности на проверку ограниченной части системы. y Они могут служить документацией и примерами, показывающими инженерам, как использовать тестируемую часть системы и как эта система должна работать. Благодаря многочисленным преимуществам большинство тестов в Google — юнит- тесты, и мы рекомендуем инженерам стремиться к тому, чтобы юнит-тесты составляли 232 Глава 12. Юнит-тестирование около 80 % тестовых наборов. Следуя этой рекомендации и ожидая вышеназванных выгод, в течение рядового рабочего дня инженер Google запускает несколько тысяч юнит-тестов (прямо или косвенно). Тестирование занимает значительную долю рабочего времени инженеров, поэто- му в Google уделяется большое внимание удобству сопровождения тестов. Тесты должны «просто работать»: после их написания инженер должен забыть о них, пока они не потерпят неудачу из-за реальной ошибки по понятной причине. Основная часть этой главы посвящена изучению удобства сопровождения тестов и методов его достижения. Важность удобства сопровождения Представьте такой сценарий: Мэри добавила в продукт новую простую функцию из 20 строк кода. Но в ответ на это автоматизированная система тестирования насыпала полный экран ошибок. И Мэри провела остаток дня, исследуя их. Изменение в коде не содержало фактической ошибки, но нарушало предположения тестов о внутренней структуре кода, что требовало обновления самих тестов. Часто Мэри было трудно понять, чего именно хотели тесты, поэтому ее исправления сделали тесты еще более трудными для понимания в будущем. В итоге работа, которая не должна была занять много времени, растянулась на часы напряженного труда, истощая продуктивность и подрывая моральный дух Мэри. В данном случае тестирование имело эффект, противоположный ожидаемому, потому что снизило продуктивность, не улучшив при этом качество тестируемого кода. Ин- женеры в Google сталкиваются с такой проблемой каждый день. У нее нет простого решения, но многие наши сотрудники работают над созданием наборов шаблонов и практик, помогающих преодолеть ее, и мы советуем всем в нашей компании при- соединиться к этому благому делу. Мэри не виновата в проблемах, с которыми ей пришлось столкнуться, и она ничего не могла сделать, чтобы избежать их: плохие тесты должны быть исправлены до того, как попадут в репозиторий, чтобы они не затронули других инженеров. В целом эти проблемы делятся на две категории: хрупкие тесты, которые ломаются в ответ на безвредные изменения, и неясные тесты, после провала которых трудно определить, в чем причина неудачи, как ее устранить и что именно должны были делать эти тесты. |