Внедрение модульного тестирования в компании, которая этого не делает

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

Отзывы разработчиков:

• Мы знаем, что тестирование ценно
• Но вы всегда меняете спецификации, так что это пустая трата времени
• И ваши сроки так сжаты, что у нас все равно не хватает времени для тестирования

Отзывы от генерального директора:

• Я бы хотел, чтобы в нашей компании было автоматизированное тестирование, но я не знаю, как это сделать
• У нас нет времени на написание больших технических документов

Как разработчики получают спецификации сейчас? Из уст в уста или слайд PowerPoint. Очевидно, это большая проблема. Мое предложение таково:

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

Ну, если вы когда-нибудь были в компании, которая была в такой ситуации, как вы решили проблему? Этот подход кажется разумным?

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

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

Одним из важных условий для включения модульного тестирования является то, что сроки не должны определяться руководством заранее, а должны основываться на оценках работы разработчиками (которые, в свою очередь, должны включать в свои оценки время, необходимое для написания надлежащих модульных тестов). Или, если установлен конечный срок, объем поставки должен быть предметом переговоров. Никакое количество (неправильного) управления не может изменить фундаментальную истину о том, что определенное количество разработчиков может предоставить только определенное количество качественной работы за определенный промежуток времени.

Параллельно с этим начните обсуждение наилучшего способа уточнения и документирования требований и превращения их в приемочные испытания высокого уровня. Это более длительный процесс последовательной доработки, который может легко занять годы, чтобы достичь лучшего, стабильного состояния во всей организации. Из вашего описания одна вещь кажется вполне достоверной: попытка исправить постоянно меняющиеся требования путем написания больших технических документов заранее не сработает . Вместо этого рекомендуется перейти к более гибкому подходус частыми выпусками программного обеспечения и демонстрациями для пользователей, и множеством дискуссий о том, чего они на самом деле хотят. Пользователь имеет право в любое время изменить свое мнение о требованиях, однако каждое изменение имеет свою стоимость (время и деньги). Разработчики могут оценить стоимость каждого запроса на изменение, что, в свою очередь, позволяет пользователю / владельцу продукта принимать обоснованные решения. «Конечно, это изменение функции было бы неплохо ... но если оно задержит выпуск этой другой важной функции и будет стоить так дорого, давайте сейчас отложим ее».

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

Мой опыт с переходом

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

Недавно мне предложили использовать Test Driven Development, и я обнаружил, что это полное откровение. Теперь я твердо убежден, что у меня нет времени не писать юнит-тесты .

По моему опыту, разрабатывая с учетом тестирования, вы получаете более чистые интерфейсы, более сфокусированные классы и модули и, как правило, более твердый , тестируемый код.

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

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

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

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

Мой совет

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

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

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

Всегда оставляйте лагерь чище, чем вы его нашли.

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

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

Чего вы хотите избежать, так это тратить целую кучу усилий разработчиков на написание тестов, которые никогда не понадобятся ( YAGNI работает так же хорошо для тестового кода, как и для рабочего кода * 8 '), никогда не будет использоваться снова и деморализует людей в думая, что тесты бесполезны в конце концов.

Резюме

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

Первое, что нужно сделать, - это сконцентрироваться не на тестировании, а на правильности всего процесса. Нет смысла тестировать что-либо, если вы не до конца понимаете, что он должен делать!

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

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

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

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

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

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