Agile без юнит-тестов

Имеет ли смысл говорить о «гибкой разработке» или утверждать, что вы применяете «гибкую методологию», если кодовая база, над которой вы работаете, имеет 0% покрытия модульными тестами? (А вы, как команда, ничего с этим не делаете).

Чтобы было понятно: для меня это не имеет смысла. По своему личному опыту я обнаружил, что модульные тесты - это единственный инструмент, который позволяет вам быть действительно «гибким» (т.е. реагировать на изменения, улучшать свой дизайн, делиться знаниями и т. Д.), А TDD - единственная практика, которая ведет вас туда ,

Может быть, есть и другие способы, но я до сих пор не понимаю, как они могут работать.

Чтобы быть педантичным, ничто в Agile Manifesto или Scrum Guide не содержит ссылок на технические приемы, такие как модульное тестирование или TDD. Так что, да, теоретически вы могли бы делать это рано и часто, уделяя особое внимание совместной работе и ценности без них, и называть себя Agile, у вас даже может быть гибкость .

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

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

Гибкий манифест просто утверждает:

Индивидуумы и взаимодействия над процессами и инструментами

Рабочее программное обеспечение над полной документацией

Сотрудничество с клиентом в процессе переговоров

Реагирование на изменения после плана

Никаких упоминаний о модульных тестах нет. Даже в 12 принципах не упоминается тестирование.

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

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

Рабочая программа  над исчерпывающей документацией.

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

Модульное тестирование (в контексте темы) замедлит вашу фазу кодирования на более ранней стадии, но будет стоить того, как вы прогрессируете, делая разработку намного быстрее. Это дает вам точный контроль зерна при тестировании на уровне кода, а также делает ваш проект масштабируемым, дает вам уверенность в том, что ваше программное обеспечение работает и может легко справиться с регрессией; что сделает ваше развитие гибким.

Это абсолютно логично. Agile - это не тестирование, как уже упоминалось, а конкретный ответ на ваш вопрос:

Нет, вам совсем не нужно юнит-тестирование.

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

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

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

Это не обязательно. Тестирование прекрасно, когда есть люди, которые действительно знают, как его использовать. Когда вы этого не делаете, это не только не обязательно, но и становится обязательством. Я бы сказал, что есть много программистов, которые не очень опытны в этом.

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

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

Я хотел бы возразить (другие ответы), что манифест Agile четко говорит об этом, а именно:

Постоянное внимание к техническому совершенству и хорошему дизайну повышает маневренность.

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

Организационная Ловкость ограничена Технической Ловкостью

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

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

Я изобрел экстремальное программирование, чтобы сделать мир безопасным для программистов. - Кент Бек

В Scrum отсутствуют какие-либо технические приемы, но Джефф сказал об этом следующее:

Я никогда не видел гиперпродуктивной команды Scrum, которая не использовала бы практики разработки Extreme Programming. - Джефф Сазерленд

Цитируется из этой статьи: http://ronjeffries.com/articles/017-02ff/gathering2017/

Я ожидаю, что команды Scrum без технических практик в конечном итоге с помощью ретроспективы придумают аналогичную практику. Вы тоже хотите быть сверхпродуктивным?

Модель Agile fluence упоминает ее на уровне двух звезд:

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

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

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

Как вы думаете, каким будет ответ, если мы спросим некоторых подписантов манифеста, таких как Роберт С. Мартин, Мартин Фаулер или Кент Бек? Может быть, они скажут, что это зависит, но, как правило, это то, что вы должны сделать.