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

Вам действительно нужно сначала выполнить BDD/TDD в тестовом режиме?
Вам действительно нужно сначала выполнить BDD/TDD в тестовом режиме? - cdc @ Unsplash

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

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

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

Есть предположения?

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

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

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

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

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


LetsCodeIt, 27 мая 2023 г., 01:34