Что такое Разработка через тестирование? Это требует, чтобы иметь начальные проекты?

Используйте всплывающее окно "text visualizer" для ввода значения и скопируйте его в буфер обмена. Он будет неубранным.

Это проблема 3-й нормальной формы .

Опция 1 находится в 3-й обычной форме. Производные данные отсутствуют. Расчет должен выполняться для каждого запроса. Из-за этого обновления можно делать на любом поле, ничего не нарушая.

Опция 2 приводит к разрыву 3-й нормальной формы. При этом сохраняются производные данные. Вычисления не выполняются во время запроса, что делает их намного быстрее. Однако обновление, которое также не приведет к повторному вычислению, приведет к несогласованности данных. Это называется "аномалией обновления". Обновление приводит к несогласованности производного поля данных.

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

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

1. Используя структуру модульных тестов (я написал свой собственный), пишите код, как вы хотите его использовать, и тесты, чтобы убедиться, что возвращаемые значения и т.д. верны. Это гарантирует написание только кода, который вы действительно собираетесь использовать. Я также добавляю еще несколько тестов для проверки краевых случаев.
2. Компиляция - вы получите ошибки компилятора!!!
3. Для каждой ошибки добавьте объявления, пока не получите ошибки компилятора. Это гарантирует наличие минимальных деклараций для кода.
4. Ссылка - вы получите ошибки компоновщика!!!
5. Запишите код реализации, достаточный для удаления ошибок компоновщика.
6. Выполнить - единичные тесты завершатся неуспешно. Запишите достаточно кода для успешного выполнения теста.

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

Мне нравится этот метод. Заставляет меня чувствовать себя внутри теплой и нечёткой.

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

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

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

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

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

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

Это теория :-) На практике вы столкнетесь с парой проблем, но это работает довольно хорошо. Вернее, он работает лучше, чем все, что я встречал до сих пор.

Написание теста сначала заставляет вас подумать о проблемной области и действует как своего рода спецификация. Затем на 2-м шаге вы переходите в область решения и реализуете эту функциональность.

TDD хорошо работает итеративно:

1. Определите исходную проблемную область (может быть небольшой, эволюционный прототип)
2. Реализуйте ее
3. Увеличьте проблемную область (добавьте функции, увеличьте прототип)
4. Рефакторинг и реализация it
5. Повторите шаг 3.

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

См. Соответствующий вопрос. TDD: хорошо для начинающего?

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

Его следует называть Test Driven Design , потому что так оно и есть.

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

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

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

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

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