Должен ли я использовать TDD для разработки своих клиентов и библиотек?

Question

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

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

Answer 1

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

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

Теперь изначально тесты не пройдут. Они должны. Только когда вы предоставите правильную реализацию, тесты пройдут успешно. Как только тесты пройдут успешно, вы, по сути, закончили; если, конечно, нет дополнительных требований.

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

Answer 2

Я отвечу на ваш вопрос более подробно ниже после того, как дам некоторую информацию о TDD.

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

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

Теперь, чтобы ответить на ваш вопрос.Поскольку TDD - это процесс проектирования, а не процесс тестирования, он помогает использовать TDD в той части кода, которая является разумной, поскольку везде, где вы его используете, ваш дизайн будет выигрывать от процесса TDD.На самом деле, я предпочитаю начинать реализацию функций, начиная с клиента, потому что это помогает мне сначала сосредоточиться на клиентских сценариях (см. Эту ссылку о Presenter First для получения дополнительной информации).Как правило, как это работает, если я что-то реализую с помощью Model-View-Controller / Model-View-Presenter / Model-View-ViewModel, я начну использовать TDD с Controller / Presenter / ViewModel, не буду тестироватьпредставление, потому что это будет тонкая обертка без логики (и ее реализация и поддержка для проверки представлений с помощью автоматических тестов дорогостоящая), и она будет перемещать вещи в модель, как это имеет смысл.

Answer 3

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

Answer 4

Зачем относиться к этому по-другому?Это все еще код, который вы должны знать, если он не работает.И дизайн должен быть достаточно гибким, чтобы принять изменения в будущем.Похоже, TDD должен помочь.

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

Answer 5

Должен ли этот клиентский код быть построен с использованием концепции TDD?

Да.Весь код написан таким образом.

Вы пишете тесты для этих клиентов?

Да.Как еще вы узнали бы, что это работает?

Это TDD исключительно о дизайне библиотеки,

Нет.

или мне нужнобеспокоиться о клиентском коде?

Очевидно, вы должны использовать TDD для всех кодов всех времени.В противном случае вы не используете тестирование для разработки.Это не TDD, если дизайн не основан на тестировании.

Answer 6

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

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

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