Учитывая короткий (2-недельный) спринт, когда-либо приемлемо воздержаться от TDD для “добиваний цели”? [закрытый]

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

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

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

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

Из вашего описания вы на самом деле не делаете TDD, поскольку тесты не заводят дизайн. Более того, вы делаете тестирование подразделения, что все еще хорошо.

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

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

, я нашел Этот дизайн, ориентированная на тестируемой тестируемой конструкции Final «дизайн» быстрее: в меньшем количестве итераций, и часто первый выстрел - последний. Обычно необходимы дизайнерские итерации, поскольку программа разработана без каких-либо чеков реальности, а последующие усилия по реализации и попытки использовать дискретирование. С TDD проверка реальности на месте все время. Этого может быть достаточно, чтобы убедиться, что вы не пропустите метку и не должны переделать вещь.

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

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

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

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

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

В моем опыте, написание правильных модульных тестов, не менее распространены в , как минимум , если написать код, который он проверяет, поэтому у меня трудно увидеть, как вы собираетесь Напишите тесты в «день или два».

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

Две крайности должны быть осторожны:

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

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

Нет прямого способа сделать это.

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

Проверьте эту ссылку на наличие нескольких способов: http://ajaxpatterns.org/On-Demand_Javascript

Мой любимый вариант (не всегда применим):

<script src="dojo.js" type="text/javascript">
dojo.require("dojo.aDojoPackage");

Закрытие Google также обеспечивает аналогичную функциональность.

У меня недостаточно контекста, чтобы дать правильный ответ, но я предложу вам максимально сделать код неизменным . Используйте поля public final . Больше не получает или setters : каждое поле должно быть определено конструктором . Ваш код короче, удобочитаем и не позволяет писать код с побочными эффектами.

Это не мешает передавать пустые аргументы конструктору, хотя... Вы по-прежнему можете проверить каждый аргумент в соответствии с предложением @ cletus, но я предложу вам бросить IllegalArgumentException вместо StartPointerException , который не дает нового намека на то, что вы сделали.

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

Надеюсь, это поможет.

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

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

Вот один случай, когда это будет приемлемо:

У вас есть новый продукт, который вряд ли кто-то использует, и вы продаете {{ 1}} человек собирается на отраслевую конференцию, чтобы продемонстрировать это. Вы доверяете ей танцевать вокруг любых ошибок, которые оставляют. Конференция вызовет интерес к вашему продукту, и продажи будут осуществляться в следующие 3–6 месяцев. У вашей компании есть 8 месяцев в банке .

Один раз это было бы неприемлемо:

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

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

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

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