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

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

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

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

есть идеи?

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

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

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

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

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

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

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

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

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

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

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

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