Каковы хорошие примеры * совершенно приемлемых * подходов, которые не используют / нуждаются / требуют разработки на основе тестирования?

Question

Цикл TDD равен test, code, refactor, (repeat) и затем отправляется . TDD подразумевает разработку, основанную на тестировании, в частности это означает понимание требований, а затем написание тестов, прежде чем разрабатывать или писать код.

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

---

Каковы хорошие примеры совершенно приемлемых подходов, которые не используют / не требуют / требуют разработки, управляемой тестами?

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

• Проверка качества вашего продукта - Сосредоточение усилий на развитии навыков тестирования / QA может быть проблематичным, особенно если вы не работаете в первую очередь над требованиями и разработкой ... симптом этого включает в себя сортировку ошибок, когда разработчикам приходится иметь дело с множеством различных ошибок, необходимо использовать форму сортировки - каждый цикл разработки становится все хуже и хуже, программисты работают все больше и больше часов, спят все меньше и меньше, стараются сохранить идти в марше смерти, пока они не будут уничтожены.
• Суеверие ... вера в вещи, которые вы не понимаете - это может включать заимствование кода, который, как вы считаете, был доказан или проверен откуда-то, например. унаследованный код, мастер создания магического кода или проект с открытым исходным кодом, и вы идете вперед, взламывая бурю модификаций, вставляя FaceBook Connect в свой пользовательский интерфейс, изобретая некоторые новые магические функции на лету (например, гибридное приложение с использованием API Twitter). , GoogleMaps API и, возможно, Zappos API), демонстрируя ваш крутой новый «продукт» нескольким людям, а затем записывая простую «спецификацию» и список «тестовых случаев» и передавая их Mechanical Turk для тестирования. (Дополнительные баллы начисляются за уверенность, что ваш продукт будет следующим Facebook, Twitter или YouTube.)

Answer 1

Cleanroom Software Engineering - это методология, которая с одной стороны звучит чрезвычайно жестко, статично, "не маневренно" и в значительной степени напротив TDD, но с другой стороны это на самом деле очень похоже. Например, он очень итеративный, как и все Agile методы. Как и TDD, вы сначала пишете спецификацию, но в отличие от TDD эта спецификация принимает форму математического доказательства правильности, а не исполняемого теста.

Где цикл TDD равен

1. Укажите
2. код
3. Рефакторинг
4. Продемонстрировать правильность с помощью исполняемых спецификаций

Цикл "Чистая комната"

1. Укажите
2. код
3. Рефакторинг
4. Докажите правильность
5. (тест)

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

Из того, что я прочитал, показатели производительности Cleanroom очень похожи на показатели TDD, что позволяет мне полагать, что значение real на самом деле отсутствует в части тестирования, это находится в мышлении части. Было бы интересно провести эксперимент, в котором вы заменяете «красную» часть TDD простым секундомером, который блокирует вашу клавиатуру на 30 секунд, прежде чем вы сможете написать новый метод.

Answer 2

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

• Интерактивный пользовательский интерфейс, как правило, очень сложно тестировать автоматически, многие вещи на самом деле зависят от реального пользовательского опыта иТрудно проверить это без реального человека - QA.
• Некоторые вещи не могут быть "измерены" или "проверены", а скорее переданы человеку для проверки.Например, когда вы разрабатываете алгоритм обработки изображений, который должен быть встроен в какое-либо устройство, очень трудно определить, что такое «правильный» подход или даже измерить его.Не говоря уже о том, что некоторые случаи очень сложно протестировать.

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

Есть все основания не проверяться автоматически.

Answer 3

дефектное развитие - мы иногда вынуждены следовать этому, когда заинтересованные стороны хотят сделать 1-летний проект в течение 3-4 месяцев, сохраняя все остальное постоянным. ;-)

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