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

27

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

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

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

Злая Жаба
источник
14
У Agile гораздо больше шансов на успех с помощью автоматизированного тестирования для его резервного копирования. Я был вынужден применять Agile без тестов раньше, и это ловушка. Это просто удобный способ накопить технический долг быстрее, чем раньше.
MetaFight
5
TDD не обязательно единственная практика, которая ведет вас туда. Это обычное явление. Лично я считаю BDD более прагматичным подходом.
MetaFight
6
«У Agile гораздо больше шансов на успех с помощью автоматического тестирования для его резервного копирования», как и в случае с не Agile-проектами. Я думаю, что автоматическое тестирование довольно ортогонально используемой методологии: оно повышает уверенность в правильности кода и помогает поддерживать его в чистоте.
Джорджио
Кстати этот вопрос смешал юнит-тест и TDD, вы можете пройти юнит-тест без TDD.
Вальфрат,
Читая ответы здесь, я удивляюсь, насколько многое изменилось с тех пор, как я научился проворному в середине 00-х. TDD и парное программирование считались НЕОБХОДИМЫМИ гибкими методами для поддержания высокого качества кода в высоком темпе.
номен

Ответы:

36

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

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

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

Резиновая утка
источник
Нужно ли следовать гибкому манифесту, чтобы быть гибким?
Джеффо
Нет @JeffO. Нет, но это, безусловно, помогает. Я отредактировал, чтобы уточнить мои намерения.
RubberDuck
1
ИМО самые гибкие программисты - это те, кто очень прагматичен, хотя никогда не слышал о гибком манифесте.
Джорджио
1
Я не могу не согласиться с тобой там @ Джорджио. Я был в гибкой команде за годы до того, как кто-либо из нас когда-либо слышал о Agile.
RubberDuck
2
@CortAmmon - Если вы хотите определить Agile (большое «A», гибкое, как в вашей методологии), я бы с вами согласился, но если вы хотите быть гибким (небольшое «a», как в действительности, чтобы быть гибким, чтобы вы могли лучше обрабатывать изменения ), то вам не нужно следовать какой-либо конкретной методологии вообще. Если вы можете сделать водопад и по-прежнему справляться с изменениями (сложно, но не невозможно), кого это волнует?
JeffO
29

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

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

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

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

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

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

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

Дэвид Арно
источник
4
Трудно понять, как команда может поддерживать работающее программное обеспечение в любой среде без тестов.
Брайан Оукли
6
То, что что-то трудно увидеть, не делает его невозможным
Ampt
8

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

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

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

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

Axel
источник
3
Вы можете проверить это вручную. Вам не нужны юнит-тесты для этого. Они помогают. МНОГО. Они как лучшая вещь, которая может улучшить процесс. Но они ни в коем случае не являются необходимыми для доставки программного обеспечения.
Т. Сар - Восстановить Монику
Да, конечно. Я не говорил, что вы не можете сделать это вручную. Я сказал любой вид теста. Я не заявлял о каких-либо разногласиях по поводу тестирования. А что касается вашего ручного тестирования, то с вашей точки зрения, с другой стороны, вы можете быть гибкими, сталкиваясь с регрессами.
Аксель
Я понимаю вашу точку зрения. Однако возникает вопрос о специальных тестах , а не о тестах в целом. Чтение вашего ответа в контексте вопроса заставляет вас рассматривать ваше тестирование как «модульное тестирование»!
Т. Сар - Восстановить Монику
Там, простите за это.
Аксель
2
@ThalesPereira, модульный тест, который говорит вам, что изменение, которое вы внесли сорок секунд назад, сломало что-то, намного более гибко, чем отчет, который вы получили из отдела контроля качества, в котором говорится, что что- то , что кто-то изменил три дня назад, сломало его.
Соломон Медленный
2

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

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

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

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

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

gbjbaanb
источник
Вы можете запустить гибкий процесс только с интеграционным тестированием. Это теоретический или из опыта?
Р Саху
1

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

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

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

JeffO
источник
1

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Нильс ван Реймерсдал
источник
1
Дело в том, что это не должен быть «модульный тест», вы можете просто запустить интеграционный тест и подумать, что этого достаточно. Однако, если у вас ничего нет и вы все тестируете вручную, вы, скорее всего, станете медлительным, чтобы быстро реагировать на изменения или доставлять довольно много регрессии на регулярной основе.
Вальфрат,
2
С технической точки зрения это не так, но тесты на более высоких уровнях часто более хрупкие, их сложнее поддерживать и, вероятно, замедляют в конце, если вам приходится их много. Мне нравится, как говорит Мартин Фаулер: «Если вы получили сбой в высокоуровневом тесте, у вас есть не только ошибка в функциональном коде, но и отсутствующий или неправильный модульный тест». от martinfowler.com/bliki/TestPyramid.html
Нильс ван Реймерсдал
Тестируйте на более высоком уровне, не проверяйте одни и те же вещи, поэтому вы пропускаете дыры, но считаете, что в настоящее время риск достаточно высок Для какого-то сайта этого может быть достаточно, для критической финансовой системы -> никак.
Вальфрат