Короткий вопрос: как вы следите за Test-Driven Development в проекте, который охватывает несколько языков?
В частности, я пишу веб-приложение, которое использует JavaScript и PHP, и я хочу следовать принципам TDD, но я не уверен, как их интегрировать. Запускаю ли я отдельные наборы тестов для разделов JS и PHP и использую макеты в комплекте JS для эмуляции ответов сервера? Есть ли методика для модульного тестирования обоих компонентов за один прогон?
Это мой первый опыт использования Test-Driven Development, поэтому любой совет, которым вы можете поделиться о том, как сделать его менее устрашающим, был бы полезен. Причина, по которой я выбрал это, заключается в том, что, как только я закончил создание прототипа, требования изменились, что заставило меня изменить свой дизайн. Я подумал, что если я начну все сначала, я бы хотел написать более расширяемый код со встроенным регрессионным тестированием с самого начала.
Я пишу свои тесты PHP в SimpleTest и мои тесты JavaScript в JsTestDriver. Я привык к объектно-ориентированным парадигмам, поэтому у меня есть несколько классов в PHP, и я делаю нечто подобное в JavaScript, используя наследование прототипов. Я также начал читать эту книгу о TDD в Python и эту книгу о TDD в JavaScript , но из всего, что я видел, они не описывают полное тестирование приложения (кроме использования чего-то вроде Selenium или другого веб-драйвера). выполнить приемочное тестирование переднего плана. Разве TDD просто не предназначен для разработчиков с полным стеком?
источник
Ответы:
На самом деле это было бы противоположностью модульному тестированию - модульное тестирование, особенно в стиле TDD, означает тестирование ваших компонентов изолированно . Таким образом, ответ «да»: «запускать отдельные наборы тестов для разделов JS и PHP », иначе это не модульное тестирование и не TDD.
Конечно, автоматизированные интеграционные тесты могут тестировать «оба компонента за один прогон», и вы можете использовать именно те инструменты, которые вы уже упоминали (например, Selenium). Но это, как правило, более сложные тесты, разработанные вне циклов TDD.
источник
Важно различать TDD и ATDD . AT там означает « приемочные тесты», и это относится к разработке, когда вы сначала начинаете с приемочного теста, который, вероятно, будет проверять весь стек. Это также иногда называют «разработкой, управляемой извне». Когда люди говорят о TDD, «Т» там, вероятно, относится именно к юнит- тестам.
Ключевой частью модульных тестов является изоляция тестируемого модуля от его зависимостей. Это дает вам два очень важных преимущества:
Вы можете сделать свои тесты чрезвычайно быстрыми, поэтому вы можете запускать их очень часто в рамках очень короткого цикла обратной связи. Вместо того, чтобы запускать их, скажем, каждый час, вы должны иметь возможность запускать все свои модульные тесты после каждого небольшого изменения, так что вы сразу же получите их мнение о том, что это изменение что-то сломало.
Ваши тесты могут быть нацелены на очень специфическое поведение. Если один из них завершится неудачно, вы сможете почти мгновенно определить точную природу ошибки, которую указывает тест.
Из-за важности этой изоляции вы автоматически захотите, чтобы тесты были ограничены гораздо меньшими единицами, чем заставляют вас ограничивать языковые границы. Хотя это не жесткое и быстрое правило, вы часто ожидаете, что один класс будет тестируемой единицей. Таким образом, с точки зрения TDD, проблема языка более или менее не имеет значения.
Если, с другой стороны, вы хотите использовать ATDD, убедитесь, что вы изучили ресурсы специально для этого (это часто делается как часть BDD, поэтому посмотрите также и на инструменты, нацеленные на это). Вот где-то вроде Selenium естественно вписался бы. Обычно, когда вы выполняете ATDD, вы все еще пишете модульные тесты, и фактически для того, чтобы пройти каждый приемочный тест, вы также можете протестировать его реализацию с помощью модульных тестов. Поэтому, даже если вы действительно хотите использовать ATDD, понимание того, как писать модульные тесты, все еще важно.
источник
Также вам не нужно использовать TDD для полного стека приложения. TDD как методология разработки больше подходит для логических частей приложения. Части, требующие более экспериментального подхода, такие как дизайн интерфейса, определенные взаимодействия или область базы данных, лучше выполнены в традиционном стиле, поскольку вы еще не знаете, будет ли это окончательная версия.
Но логика приложения не должна измениться в будущем, и если это произойдет, вы столкнетесь с пугающим требованием. Это делает его идеальным для набора регрессионных тестов, чтобы дать уверенность при внесении изменений в код, что является конечной целью TDD.
Дядя Боб объясняет этот путь лучше меня. https://blog.8thlight.com/uncle-bob/2014/04/30/When-tdd-does-not-work.html
источник