Вы действительно должны сначала выполнить тестирование BDD / TDD?

11

Хотя я не был в проекте TDD или BDD, или я был в некоторых, которые говорят, что они делают TDD, но довольно далеки от этого, это вещи, о которых я думаю и действительно пытаюсь прочитать столько, сколько я могу около.

Вернуться к вопросу. Когда вы делаете BDD, вы должны сначала написать «тест» и заставить его провалиться, верно? А затем реализуйте эту функцию или как вы ее называете. Но если вы доведите это до крайности, разве это не может быть какой-то нисходящей разработкой? Вы смотрите на свой пользовательский интерфейс и говорите: «Я хотел бы иметь эту функцию / поведение здесь». Затем вы исправляете свой пользовательский интерфейс для реализации этой функции и кода, который поддерживает пользовательский интерфейс. На данный момент вы не реализовали никакой бизнес-логики или логики доступа к данным, вы только что реализовали свое поведение. То, к чему я стремлюсь, вместо того, чтобы сначала писать тест, вы сначала пишете свой код пользовательского интерфейса. В некоторых случаях это должно приводить к одному и тому же коду для доступа к данным и бизнес-уровня, поскольку вы используете свой код пользовательского интерфейса для определения того, что должен поддерживать ваш бизнес.

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

есть идеи?

Томас Янссон
источник
Тесты по TDD - это модульные тесты, которые управляют модулем напрямую, как если бы он проходил отдельно main. В своем нисходящем комментарии вы говорите о функциональных тестах, которые выполняют всю программу, хотя бы один main.
Макнейл
@Macneil: я не говорю о функциональном тестировании, которое тестирует всю программу, даже если вы думаете, что вы реализуете / разрабатываете свою программу сверху вниз, вы все равно должны реализовать модульный тест для всего вашего открытого кода. То, что вы делаете это сверху вниз, не означает, что вы не можете сделать разные слои абстрактными, поэтому вы можете изолировать все слои самостоятельно.
Томас Янссон
1
@Macneil: это распространенное заблуждение. Тесты TDD не являются юнит- тестами. TDD тестирует функции , которые не имеют установленной шкалы.
Стивен А. Лоу
2
Но есть установленная шкала: тест должен быстро выполняться в TDD. Существуют тесты, которые также должны выходить за рамки TDD. В целом, TDD - это план развития, а не план тестирования.
Макнейл
@Macneil: «быстро» это относительный термин. Набор тестов в моем последнем проекте выполняется примерно за 30 минут. Он заменяет 8 часов ручного тестирования. Этого достаточно быстро!
Стивен А. Лоу

Ответы:

8

Вы говорите о BDD с точки зрения высокого уровня тестирования вашего пользовательского интерфейса. На этом уровне тестирование немного более пушистое, чем ниже в вашем Javascript / коде на стороне сервера.

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

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

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

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

Грег К
источник
Я думаю, вы правы. Это пришло ко мне, когда я попробовал ruby ​​на рельсах этим летом, там у них есть тест bdd, который управляет пользовательским интерфейсом, который позже управляет реализацией базовых классов.
Томас Янссон
17

Да! В противном случае вы получаете тестирование на основе разработки .

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

azheglov
источник
3
Первая строка потрясающая.
EpsilonVector
По сравнению с TDD, это правда, но выполнение действий сверху вниз должно очень хорошо совмещаться с BDD, верно? Я смотрю на графический интерфейс и указываю желаемое поведение, конечно, я не пишу «тест поведения» сразу, но я определил поведение через пользовательский интерфейс до того, как реализовал его.
Томас Янссон
15

Если вы сначала не пишете свои тесты, вы не продвигаете разработку через свои тесты. Ergo, ты не занимаешься разработкой на основе тестов!

Фрэнк Шиарар
источник
Честно говоря, вопрос не в том, стоит ли при выполнении BDD (а не TDD) сначала писать тест?
bytedev
Не стесняйтесь заменить «тест» на «поведение». Я не видел ничего, что могло бы убедить меня в том, что в глубине души есть большая разница между TDD и BDD. Фокус, может быть. Но основная идея? Не так много.
Фрэнк Шеарар
Не согласен с тем фактом, что вы не занимаетесь разработкой на основе тестов. Вы делаете это не в соответствии с определением ключевого термина, но пока вы разрабатываете тесты для своего кода, ваш код определенно определяется тестами, независимо от того, когда вы их пишете.
альтернатива
TDD специально означает написание тестов перед кодом. Если вам это не нравится, поговорите с Кентом Беком, который придумал этот термин. Написание тестов после вашего кода может в некоторой степени стимулировать ваш код , но вы все равно можете заставить себя поверить, что вы разрабатываете свой код с помощью тестов, а не сами. И эти тесты сложнее написать, потому что вам часто приходится менять непроверенный код . Видел это слишком часто, чтобы упоминать.
Фрэнк Шиарар
@FrankShearar Я признал, что это не TDD в соответствии с тем, что сказал Кент Бек, но, честно говоря, мне все равно, что сказал какой-то случайный человек. Совершенно возможно управлять дизайном кода с помощью тестов без предварительного написания тестов.
альтернатива
4

Если вы хотите работать таким образом, пойти на это. Но это не тест-ориентированная разработка.

Дон Роби
источник
3

То, что вы описываете, очень похоже на подход Front-Ahead Design . К сожалению, Front-Award Design - сатирический удар Алекса Пападимулиса в ловких методах.

user281377
источник
Мне было интересно, если вы знаете какие-нибудь статьи, которые сопротивляются в FAD, разоблачая его сатирический удар?
CL22
3

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

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

Майкл Шоу
источник