Кто занимается тест-ориентированной разработкой?

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

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

С какими типами магазинов, компаний и клиентов лучше всего работает разработка, основанная на тестировании? Какие типы проектов имеют тенденцию быть способствующими TDD?

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

Мой босс сегодня накормил меня этим, думаю, я собираюсь украсть, как будто он крал у кого-то другого.

"Ожидаете ли вы, что плотник измерит доску, прежде чем разрезать ее?"

В старших классах я брал урок по мастерской по дереву и работал в школе на стройке. Наша мантра всегда была «отмерь дважды, отрежь один раз», за которой последовал саркастический ответ: «Я обрезала ее и обрезала снова, а она была еще слишком короткой!»

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

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

Вы можете протестировать код привода даже в проекте с водопадом, это инженерная дисциплина, а не техника управления проектом.

Я ни в коем случае не фанат TDD, но он многому научит вас в разработке программного обеспечения.

Потерпи меня, так как это будет иметь характерный .Net аромат: p

Что касается типов проектов, поддающихся тестовому подходу, я бы хотел обратить внимание на некоторые вещи:

• Вы имеете дело с существующей кодовой базой? Часто слишком дорого дооснащать набор тестов. Получить представление о том, сколько унаследованного технического долга
• некоторые платформы и фреймворки изначально недружелюбны к тестированию. Недавний опыт, который запечатлелся у меня в голове - например, SharePoint, очень труден (но не невозможен) для TDD. Для подобных вещей вам, возможно, придется прибегнуть к коммерческому изоляционному продукту, как TypeMock.
• некоторые подходы к реализации лучше подходят для TDD, чем другие. Например, ASP.Net с выделенными кодами - не очень тестируемый. ASP.Net MVC - тестируемый. Silverlight с выделенными кодами - не очень тестируемый. Silverlight с MVVM - тестируемый.

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

+1 к комментарию mpenrow о том, чтобы не сообщать mgmt, если у них возникла проблема: p

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

Вы также можете сделать хорошие бизнес-кейсы:

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

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

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

• TDD очень много думает о задаче перед ее началом. Это по принципу «измерять дважды, вырезать один раз» - дополнительное измерение добавляет незначительное количество времени к задаче, но позволяет избежать потери вашего самого ценного ресурса - часов разработки).

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

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

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

Если вы объясните «я пишу тесты», то «Силы, которые будут» могут сказать: «О, мы можем это устранить!» Но если вы никому не говорите, то у вас все еще есть тесты как остаток процесса кодирования.

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

К сожалению, я не получил возможности использовать его в по-настоящему классическом для меня тестовом смысле, поэтому я не могу сказать «я! Я! Я делаю это!». Я предполагаю, что вопрос заключается в том, «какие отрасли / компании используют TDD по всем направлениям», а не «может ли кто-нибудь внедрить TDD в свою повседневную жизнь?». Я согласен, что отдельный разработчик может полностью выполнить TDD, не заставляя делать это всю группу, я просто не думаю, что это был вопрос.

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

• Не существует большой существующей кодовой базы до начала TDD

• Компания не огромна и поэтому не имеет большого количества откатов «мы всегда так делали».

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

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

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

• Заинтересованные стороны, которые вкладываются в процесс.

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

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

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

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

Так что, я думаю, вам нужно провести какие-то LearningTests, отдельные проверки концепций и переписать их потом и т. Д., Или я ошибаюсь?

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

Я действительно вижу положительные стороны TDD и im на лодке, но для начинающих очень тяжело, когда код, который ты пишешь, отнимает у тебя почти вдвое больше времени (а у тебя есть коллеги, которые вообще не видят плюсов и насмехаются над тобой) с RAD)

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

Я делаю это. Ход наших пользовательских историй отслеживается на доске Канбан, на которой есть «Есть тест?» столбец слева (вверх по течению) развития.

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

Цикл обратной связи при приемочном тестировании довольно длинный: на завершение истории может уйти несколько дней. Разработка имеет свои собственные, более короткие петли обратной связи TDD.

"[... без тестового стиля ...] Более сродни Agile ...."

Это полное искажение Agile. Определение done является ключевым компонентом Agile, и одним из столпов, на которых он основывается, является автоматическое приемочное тестирование (то, что я описал выше, является одним из способов сделать это.) Если в качестве метода реализации Agile используется экстремальное программирование (XP), то ATDD / BDD и TDD предписаны.

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

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

Это сложная привычка, и она требует участия руководства, но, когда ваши тесты начинают прорываться на полпути развития, это может спасти жизнь!

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

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

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

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

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

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

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

Торговая площадка ...

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

Сначала проверка означает, что сначала вы кодируете свое намерение, а затем подтверждаете, что ваш код выполняет это намерение. Это обеспечивает фокусировку и позволяет вашему коду делать только то, что задумано, и не более (читай, не раздувай). Это исполняемая спецификация и документация одновременно (если ваш тест хорошо написан, и тесты должны быть такими же читаемыми / чистыми, как и системный код, если не больше!).

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

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

По моему мнению, индустрия разработки программного обеспечения (в целом) в настоящее время не работает, тот факт, что тестирование вашего ПО НЕ является нормой.

Представьте себе это в других отраслях: медицина, авиация, автомобили, косметика, мягкие игрушки, алкогольные напитки и т. Д. Я попросил свою невесту назвать индустрию, в которой они не тестируют продукт, а она не может!

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

Один момент, который я бы оспорил в вашем вопросе ...

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

Быть «Agile» не означает, что вы не будете проходить тесты, первым участником, внесенным в список на agilemanifesto.org, является Кент Бек , создатель XP и TDD!

Две книги, которые я очень рекомендую, если вы заинтересованы в TDD, или просто не читали их, и увлеченный программист (это все правильно читают?;)

Растущее ориентированное на программное обеспечение, ориентированное на тесты

Чистый код - Роберт С. Мартин («Дядя Боб») Серия

Эти две книги дополняют друг друга и объединяют много смысла в несколько страниц.

Спасибо, что задали этот вопрос :)

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

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

• 73 000 строк кода
• 91 378 600 строк тестового кода

См. Http://www.sqlite.org/testing.html.