Data-Driven тесты в MS-Test для модульного и приёмочного тестирования
Я бы сразу хотел подчеркнуть тот факт, что мир модульных тестов и мир приёмочных тестов через пользовательский интерфейс – это очень разные миры: со своими законами, разными возможностями и ограничениями. И если мир модульных тестов работает на покрытие каждой части приложения по отдельности и в изоляции, то тесты через пользовательский интерфейс – это эмуляция работы пользователя с системой, по большей части через нажатие кнопок и набор текста, которые в итоге сливаются в более крупные бизнес-сценарии.
Не редко оказывается так, что даже если инструмент предоставляет очень хорошие возможности для модульных тестов – то эти возможности оказываются практически неприменимы для UI-тестов.
Так случилось и в моей практике, когда я решил использовать data-driven тесты в фреймворке Ms-Test. В этой статье я более детально опишу проблему и свое решение, за которое до сих пор не пойму – мне нужно гордиться или стыдиться.
Data-Driven подход в мире модульных тестов
Предположим, у нас есть метод int ConvertToNumber(string input), который на вход принимает строку с числом и возвращает это же число, только в целочисленном типе.
Пусть мы напишем один позитивный тест, (который приносит радость) например, для input = “3” и проверим, что результат будет тоже 3.
Что еще? Конечно же, граничные значения и классы эквивалентности: “-1”, “0”, “MaxInt”, “-(MaxInt)”.
Хорошо, а что если на вход попадет десятичная дробь? А если строка начинается с цифры, за которой следуют символы?
Каково должно быть правильное решение в таких разных ситуациях?
А правильного решения – нет.
Обратите внимание, что разные языки программирования обрабатывают такие ситуации по-разному. Например, JavaScript в результате операции < “10” + 1>вернет строку “101”, а в результате < “10” — 1>будет число 9. А Perl скажет: 11 и 9 соответственно. Но, отсутствие «истинного» ответа совсем не мешает нам самостоятельно придумать правильные варианты поведения и сказать, что отныне – это есмь истина, и высечь эту истину модульными тестами в камне.
Но, неужели вы собрались накопи-пастить дюжину юнит-тестов для одного несчастного метода с единственным параметром?
А почему бы не создать таблицу входных и ожидаемых значений, и передать каждую строку такой таблицы как параметр в один единственных тест.
Вначале, я сам очень удивился, что Ms-Test предоставляет достаточно богатые возможности для этого.
Пример data-driven модульного теста на Ms-Test
Для наглядности примера, в реализации ConvertToNumber, я не буду использовать Convert.ToInt32() –это было бы слишком просто. Вместо этого, предложу свою реализацию:
К сожалению, в Ms-Test пока нет возможности задать входящие и ожидаемые значения непосредственно в коде, при помощи атрибутов. Зато, есть альтернатива – использовать источники данных. И в качестве такого источника, вы не поверите, будем использовать Excel-файл.
Главное – не забыть выделить нужный фрагмент и форматировать его как «Таблица с заголовком». Иначе – магия не будет работать.
Тогда модульный тест с реализаций соединения с Excel-таблицей и чтением данных будет выглядеть следующим образом:
Да, пришлось затратить немного усилий на настройку подключения и преобразование входных данных, но, посмотрите какие наглядные результаты мы получили.
А чтобы добавить новый тест – достаточно добавить новую строку в Excel. И в код лезть не нужно, чтобы посмотреть, что же конкретно тестами покрыто, а что – нет.
Кроме того, вы можете зайти в любой из тестов, чтобы посмотреть детали ошибки или лог.
Прошу заметить, что даже на моей низко производительной машине, все 14 тестов прошли за менее чем за 1 секунду.
Не знаю как вы, но я был просто впечатлен такими возможностями и наглядными результатами.
Примечание: Для того, чтобы всё заработало, не забудьте скопировать файл matrix.xlsx в корень диска C:\
Data-Driven подход в мире тестирования через пользовательский интерфейс
К огромному моему сожалению, после того, как я взялся за UI-тесты с использованием Selenium WebDriver – моему восхищению от мега-крутой фичи Ms-Test пришёл конец.
Дело в том, что UI-тесты в любой реализации, по своей природе очень медленные, по сравнению с модульными. Тут нельзя просто так взять и вызвать функцию из ядра системы, с легкостью жонглируя контекстом и параметрами. Нет… для того, чтобы реализовать сложный пользовательский сценарий – нужно накликать множество кнопок.
Следовательно, с учетом всех возможных оптимизаций, один UI-тест может идти от 30-ти секунд до десятков минут. Всё зависит от сложности сценария.
Например, если предположить, что 1 из 14 data-driven тестов идет одну минуту – то весь набор пройдет за 14 минут.
А теперь представьте себе, что один тест упадёт по какой-то причине, например из-за того, что кнопочка на странице не успела появиться…
Не беда, скажете вы, ведь можно исправить и прогнать только упавшие тесты.
Нет. Ms-Test считает пачку data-driven тестов как один тест. Следовательно, чтобы перепрогнать 1 тест – придётся запускать все 14 вновь. И не факт, что те тесты, которые проходили раньше – вдруг не упадут. А в случае отладки, придётся не просто ставить точку останова, а настраивать условную точку останова: Visual Studio это позволяет… но, это требует дополнительных усилий и затрат времени.
Нужно было найти способ, который бы позволил перепрогнать только упавший тест. И я такой способ нашел.
Решение задачи: «цикл через наследование»
Для решения задачи, необходимо добавить в проект 2 файла: TestBase.cs и TestRows.cs.
Тогда в пространстве имён “MsTestRows.Rows.*”, появятся классы TestRows_01 … TestRows_100, которые содержат в себе от одного до ста генерированных методов.
Унаследуйте ваш TestClass от TestRows_NN с необходимым количеством методов (NN).
В результате, воспользовавшись таким извращенным маневром, мне удалось добиться возможности перезапустить только упавший тест.
Исходный код и ссылки
Примечание 2: Попробуйте реализовать ConvertToNumber так, чтобы он проходил все тесты.
Внимание: придерживайтесь “авторского стиля”.
Объясните пожалуйста что такое test-case data-driven с примерами
Объясните пожалуйста что такое test-case data-driven с примерами!
Мне понравились примеры из книги Романа Савина «Тестирование дот ком», часть 1, глава «Искусство создания тест кейсов», раздел «Тест-кейсы, управляемые данными». Они очень простые, но при этом и не игрушечные. Книгу эту легко найти)
Сам являюсь только начинающим тестировщиком, поэтому не буду свои примеры приводить, чтобы не запутать вас)
Банально, у вас есть некоторый «тест кейс», который выполняет типовое действие над исследуемой системой, но для того, чтобы система была протестирована надо выполнить этот кейс с большим количеством комбинаций входных данных и ожидаемых результатов.
Например тестирование калькулятора: аргумент1, действие, аргумент2, ожидаемый результат, точность проверки. И вот у вас таблица на 1000 строк:, разные действия, нули, отрицательные числа, вещественные числа без нуля перед точкой, большие числа, маленькие числа, проверка точности вещественных чисел. А тест кейс один.
я прав если думаю, что это несколько тест-кейсов проверяющих общую идею в результате чего обладают наличием идентичных шагов?
я прав если думаю, что это несколько тест-кейсов проверяющих общую идею в результате чего обладают наличием идентичных шагов?
я прав если думаю, что это несколько тест-кейсов проверяющих общую идею в результате чего обладают наличием идентичных шагов?
я прав если думаю, что это несколько тест-кейсов проверяющих общую идею в результате чего обладают наличием идентичных шагов?
тут имеется в виду не «управляемые данные», а тест, управляемый данными. Т.о. как говорилось выше, есть один тест, который проходится несколько раз с разными входными данными и соответствующими им ожидаемыми результатами. Получается, что это уже не один тест, а целый набор тестов.
я прав если думаю, что это несколько тест-кейсов проверяющих общую идею в результате чего обладают наличием идентичных шагов?
тут имеется в виду не «управляемые данные», а тест, управляемый данными. Т.о. как говорилось выше, есть один тест, который проходится несколько раз с разными входными данными и соответствующими им ожидаемыми результатами. Получается, что это уже не один тест, а целый набор тестов.
Спасибо!А все тест-кейсы являются управляемыми данными или нет?
Почти под все тесты в принципе можно подвести эту практику. Если это необходимо.
Почти под все тесты в принципе можно подвести эту практику. Если это необходимо.
Мне понравились примеры из книги Романа Савина «Тестирование дот ком», часть 1, глава «Искусство создания тест кейсов», раздел «Тест-кейсы, управляемые данными». Они очень простые, но при этом и не игрушечные. Книгу эту легко найти)
Сам являюсь только начинающим тестировщиком, поэтому не буду свои примеры приводить, чтобы не запутать вас)
ABAP Blog
Все о разработке в решениях от SAP
ABAP Blog
Все о разработке в решениях от SAP
Ссылки
Цитаты
Вы работаете с чистым кодом, если каждая функция делает примерно то, что вы ожидали. Код можно назвать красивым, если у вас также создается впечатление, что язык был создан специально для этой задачи.
У. Каннингем
Новое
Последние комментарии
Тестирование, управляемое данными (Data-Driven Testing)
Методология тестирования, управляемого данными (DDT) применяется в автоматизации тестирования ПО, представляет собой тестирование, выполнение и верификация которого производится на основе данных, которые хранятся в БД или любых других источниках данных.
Обычно сравнивают эталонные данные с теми, что на выходе получает система из метода (функции, программы и т.п.).
Тестирование, управляемое данными подразумевает разделение юнит тестов и данных, которые в них проверяются. Юнит тесты получают эталонные данные из некого источника и сравнивают их с результатами, полученными при тестировании объекта.
Изначально ABAP Unit не предоставляет никакого сервиса для хранения и ведения тестируемых данных, как например это делают другие фреймворки для тестирования: jUnit, nUnit. В статье пойдет речь о том как обойти это недоразумение.
В качестве подобного сервиса можно использовать контейнеры данных eCATT. Что такое eCATT и для чего он нужен можно посмотреть тут. Нас интересует один из элементов eCATT, а именно контейнер тестовых данных. Исходя из названия, становится понятно, что контейнер позволяет хранить внутри себя какие-то данные, но кроме хранения можно так же и вести (изменять) эти данные.
Рассмотрим небольшой пример, допустим, есть метод рассчитывающий тип треугольника относительно размеров его сторон, как известно из школьной программы, тип может быть следующим:
Создадим класс ZCL_TRIANGLE c указанными атрибутами:
TDD: методология разработки, которая изменила мою жизнь
На часах 7:15 утра. Наша техподдержка завалена работой. О нас только что рассказали в передаче «Good Morning America» и множество тех, кто впервые посещает наш сайт, столкнулось с ошибками.
У нас настоящий аврал. Мы, прямо сейчас, до того, как потеряем возможность превратить посетителей ресурса в новых пользователей, собираемся выкатить пакет исправлений. Один из разработчиков кое-что подготовил. Он думает, что это поможет справиться с проблемой. Мы размещаем ссылку на обновлённую версию программы, пока ещё не ушедшей в продакшн, в чат компании, и просим всех её протестировать. Работает!
Наши героические инженеры запускают скрипты для развёртывания систем и через считанные минуты обновление уходит в бой. Внезапно число звонков в техподдержку удваивается. Наше срочное исправление что-то поломало, разработчики хватаются за git blame, а инженеры в это время откатывают систему к предыдущему состоянию.
Автор материала, перевод которого мы сегодня публикуем, полагает, что всего этого можно было бы избежать благодаря TDD.
Почему я использую TDD?
Я давно уже не попадал в подобные ситуации. И дело не в том, что разработчики перестали совершать ошибки. Дело в том, что уже многие годы в каждой команде, которой я руководил и на которую я оказывал влияние, применялась методология TDD. Ошибки, конечно, всё ещё случаются, но проникновение в продакшн проблем, способных «повалить» проект, снизилось практически до нуля, даже несмотря на то, что частота обновления ПО и количество задач, которые нужно решить в процессе обновления, экспоненциально выросли с тех пор, когда случилось то, о чём я рассказал в начале.
Когда кто-то спрашивает меня о том, почему ему стоит связываться с TDD, я рассказываю ему эту историю, и могу вспомнить ещё с десяток похожих случаев. Одна из важнейших причин, по которым я перешёл на TDD, заключается в том, что эта методология позволяет улучшить покрытие кода тестами, что ведёт к тому, что в продакшн попадают на 40-80% меньше ошибок. Это то, что мне нравится в TDD больше всего. Это снимает с плеч разработчиков целую гору проблем.
Кроме того, стоит отметить, что TDD избавляет разработчиков от страха внесения изменений в код.
В проектах, в работе над которыми я принимаю участие, наборы автоматических модульных и функциональных тестов практически ежедневно предотвращают попадание в продакшн кода, который способен серьёзно нарушить работу этих проектов. Например, сейчас я смотрю на 10 автоматических обновлений библиотеки, сделанных на прошлой неделе, таких, перед выпуском которых без использования TDD, я опасался бы того, что они могут что-то испортить.
Все эти обновления были автоматически интегрированы в код, и они уже используются в продакшне. Я не проверял ни одного из них вручную, и совершенно не беспокоился о том, что они могут плохо отразиться на проекте. При этом, мне, для того чтобы привести этот пример, не пришлось долго думать. Я просто открыл GitHub, взглянул на недавние слияния, и увидел то, о чём рассказал. Та задача, которую раньше решали вручную (или, ещё хуже, задача, которую игнорировали), теперь представляет собой автоматизированный фоновый процесс. Можно попытаться сделать нечто подобное и без хорошего покрытия кода тестами, но я бы не рекомендовал так поступать.
Что такое TDD?
TDD расшифровывается как Test Driven Development (разработка через тестирование). Процесс, реализуемый в ходе применения этой методологии очень прост:
Тесты выявляют ошибки, тесты завершаются успешно, выполняется рефакторинг
Вот основные принципы применения TDD:
Как TDD может помочь сэкономить время, необходимое на разработку программ?
На первый взгляд может показаться, что написание тестов означает значительное увеличение объёма кода проекта, и то, что всё это отнимает у разработчиков много дополнительного времени. В моём случае, поначалу, всё так и было, и я пытался понять, как, в принципе, можно писать тестируемый код, и как добавлять тесты к коду, который был уже написан.
Для TDD характерна определённая кривая обучаемости, и пока новичок карабкается по этой кривой, время, необходимое на разработку, может увеличиться на 15-35%. Часто именно так всё и происходит. Но где-то года через 2 после начала использования TDD начинает происходить нечто невероятное. А именно, я, например, стал, с предварительным написанием модульных тестов, программировать быстрее, чем раньше, когда TDD не пользовался.
Несколько лет назад я реализовывал, в клиентской системе, возможность работы с фрагментами видеоклипа. А именно, речь шла о том, чтобы можно было бы позволить пользователю указывать начало и конец фрагмента записи, и получать ссылку на него, что дало бы возможность ссылаться на конкретное место в клипе, а не на весь этот клип.
Работа у меня не шла. Проигрыватель доходил до конца фрагмента и продолжал её воспроизводить, а я не имел представления о том, почему это так.
Я полагал, что проблема заключается в неправильном подключении прослушивателей событий. Мой код выглядел примерно так:
Процесс поиска проблемы выглядел так: внесение изменений, компиляция, перезагрузка, щелчок, ожидание… Эта последовательность действий повторялась снова и снова.
Для того чтобы проверить каждое из вносимых в проект изменений, нужно было потратить почти минуту, а я испытывал невероятно много вариантов решения задачи (большинство из них — по 2-3 раза).
Закон отладки Мёрфи. То место программы, которое вы никогда не тестировали, так как свято верили в то, что оно не может содержать ошибок, окажется именно тем местом, где вы найдёте ошибку после того, как, совершенно вымотавшись, внесёте в это место изменения лишь из-за того, что уже попробовали всё, о чём только могли подумать.
Я не забыл об этом и годы спустя. И всё — благодаря тому ощущению, которое испытал, всё же найдя ошибку. Вы, наверняка, знаете, о чём я говорю. Со всеми это случалось. И, пожалуй, каждый сможет узнать себя в этом меме.
Вот как я выгляжу, когда программирую
Если бы я писал ту программу сегодня, я бы начал работу над ней примерно так:
Возникает ощущение, что тут куда больше кода, чем в этой строчке:
Но в том-то всё и дело. Этот код действует как спецификация. Это — и документация, и доказательство того, что код работает так, как того требует эта документация. И, так как эта документация существует, если я изменю порядок работы с маркером времени окончания фрагмента, мне не придётся беспокоиться о том, нарушил ли я в ходе внесения этих изменений правильность работы со временем окончания клипа.
Вот, кстати, полезный материал по написанию модульных тестов, таких же, как тот, который мы только что рассмотрели.
Начиная новый проект я, в качестве одного из первых дел, выполняю настройку скрипта-наблюдателя, который автоматически запускает модульные тесты при каждом изменении некоего файла. Я часто программирую, используя два монитора. На одном из них открыта консоль разработчика, в которой выводятся результаты выполнения подобного скрипта, на другом выводится интерфейс среды, в которой я пишу код. Когда я вношу в код изменение, я обычно, в пределах 3 секунд, узнаю о том, рабочим оказалось это изменение или нет.
Для меня TDD — это гораздо больше, чем просто страховка. Это — возможность постоянного и быстрого, в режиме реального времени, получения сведений о состоянии моего кода. Мгновенное вознаграждение в виде пройденных тестов, или мгновенный отчёт об ошибках в том случае, если я сделал что-то не так.
Как методология TDD научила меня писать более качественный код?
Мне хотелось бы сделать одно признание, хоть признавать это и неловко: я не представлял себе, как создавать приложения до того, как я изучил TDD и модульное тестирование. Я не представляю, как меня вообще брали на работу, но, после того, как я провёл собеседования с многими сотнями разработчиков, я могу с уверенностью сказать, что в похожей ситуации находится множество программистов. Методология TDD научила меня почти всему, что я знаю об эффективной декомпозиции и композиции программных компонентов (я имею в виду модули, функции, объекты, компоненты пользовательского интерфейса и прочее подобное).
Причина этого заключается в том, что модульные тесты принуждают программиста к тестированию компонентов в изоляции друг от друга и от подсистем ввода-вывода. Если модулю предоставляются некие входные данные — он должен выдать некие, заранее известные, выходные данные. Если он этого не сделает, тест завершается с ошибкой. Если сделает — тест завершается успешно. Смысл тут заключается в том, что модуль должен работать независимо от остального приложения. Если вы тестируете логику работы состояния, у вас должна быть возможность делать это без вывода чего-либо на экран или сохранения чего-нибудь в базу данных. Если вы тестируете формирование пользовательского интерфейса, то у вас должна быть возможность тестировать его без необходимости загрузки страницы в браузер или обращения к сетевым ресурсам.
Кроме прочего, методология TDD научила меня тому, что жизнь становится гораздо проще в том случае, если при разработке компонентов пользовательского интерфейса стремиться к минимализму. Кроме того, от пользовательского интерфейса следует изолировать бизнес-логику и побочные эффекты. С практической точки зрения это означает, что если вы используете UI-фреймворк, основанный на компонентах, вроде React или Angular, целесообразным может быть создание презентационных компонентов, отвечающих за вывод чего-либо на экран, и компонентов-контейнеров, которые друг с другом не смешиваются.
Презентационный компонент, получающий некие свойства, всегда формирует один и тот же результат. Подобные компоненты можно легко проверить, используя модульные тесты. Это позволяет узнать, правильно ли компонент работает со свойствами, и то, корректна ли некая условная логика, используемая при формировании интерфейса. Например, возможно, компонент, формирующий список, не должен выводить ничего кроме приглашения на добавление в список нового элемента в том случае, если список пуст.
Я знал о принципе разделения ответственности задолго до того, как освоил TDD, но я не знал о том, как разделять ответственность между разными сущностями.
Модульное тестирование позволило мне изучить использование моков для тестирования чего-либо, а затем я узнал, что мокинг — это признак того, что, возможно, с кодом что-то не так. Это меня ошеломило и полностью изменило мой подход к композиции программного обеспечения.
Вся разработка программного обеспечения — это композиция: процесс разбиения больших проблем на множество мелких, легко решаемых проблем, а затем создание решений для этих проблем, которые и формируют приложение. Мокинг, выполняемый ради модульных тестов, указывает на то, что атомарные единицы композиции, на самом деле, не атомарны. Изучение того, как избавиться от моков, не ухудшая покрытие кода тестами, позволило мне узнать о том, как выявлять бесчисленное множество скрытых причин сильной связанности сущностей.
Это позволило мне, как разработчику, профессионально вырасти. Это научило меня тому, как писать гораздо более простой код, который легче расширять, поддерживать, масштабировать. Это относится и к сложности самого кода, и к организации его работы в больших распределённых системах наподобие облачных инфраструктур.
Как TDD помогает экономить рабочее время команд?
Я уже говорил о том, что TDD, в первую очередь, ведёт к улучшению покрытия кода тестами. Причина этого заключается в том, что мы не начинаем писать код реализации некоей возможности до тех пор, пока не напишем тест, проверяющий правильность работы этого будущего кода. Сначала пишем тест. Потом позволяем ему завершиться с ошибкой. Потом пишем код реализации возможности. Тестируем код, получаем сообщение об ошибке, добиваемся правильного прохождения испытаний, выполняем рефакторинг и повторяем этот процесс.
Этот процесс позволяет создать «заграждение», через которое способны «перескочить» лишь очень немногие ошибки. Эта защита от ошибок оказывает удивительное воздействие на весь коллектив разработчиков. Оно избавляет от страха перед командой merge.
Высокий уровень покрытия кода тестами позволяет команде избавиться от желания вручную проконтролировать любое, даже маленькое изменение кодовой базы. Изменения кода становятся естественной частью рабочего процесса.
Избавления от страха внесения изменений в код напоминает смазывание некоей машины. Если этого не делать, машина, в конце концов, остановится — до тех пор, пока её не смажут и снова не запустят.
Без этого страха процесс работы над программами оказывается гораздо более спокойным, чем прежде. Pull-запросы не откладывают до последнего. CI/CD-система запустит тесты, и, если тесты окажутся неудачными, остановит процесс внесения изменений в код проекта. При этом сообщения об ошибках и сведения о том, где именно они произошли, очень сложно будет не заметить.
В этом-то всё и дело.
Уважаемые читатели! Пользуетесь ли вы методикой TDD при работе над своими проектами?
Подходы к автоматизации тестирования веб-приложений
Любой современный софт, включая веб-ориентированные приложения, тестируется на наличие ошибок. Скорость идентификации этих ошибок зависит не только от инструментов, количества тестировщиков и их опыта, но и от выбранного подхода. Об этом и поговорим.
Виды подходов
В автоматизированном тестировании выделяют следующие подходы: 1) TDD (англ. Test Driven Development); 2) BDD (англ. Behaviour Driven Development); 3) KDT (англ. Keyword Driven Testing); 4) DDT (англ. Data-driven testing).
Data-Driven Testing
Это тестирование, управляемое данными. При таком подходе тестовые данные хранятся отдельно от тест-кейсов, допустим, в файле либо в базе данных. Такое разделение логически упрощает тесты.
Data-Driven Testing используется в тех проектах, где нужно выполнить тестирование отдельных приложений в нескольких средах с большими наборами данных и стабильными test cases.
Обычно при DDT выполняются следующие операции: — извлечение части тестовых данных из хранилища; — ввод данных в форму приложения; — проверка результатов; — продолжение тестирования со следующим набором входных данных.
Подход Data-Driven Testing:
Чтобы проверка приложения была успешна, потребуются разные комбинации данных.
Keyword Driven Testing
Речь идёт о тестах, управляемых ключевыми словами. Данный подход предполагает использование ключевых слов, описывающих набор действий, нужных для выполнения конкретного шага тестового сценария.
При таком подходе в первую очередь определяется набор ключевых слов, а только после этого ассоциируется функция либо действие, связанное с данным ключевым словом. Например, каждые шаги теста, такие как щелчок мышью, нажатие клавиши, открытие либо закрытие браузера описываются определёнными ключевыми словами («открыть» — openbrowser, «нажать» — click и т. п.).
При KDT-подходе вы можете создавать простые функциональные тесты на самых ранних этапах разработки и тестировать приложение по частям.
Этапы разработки KDT-тестов: 1. Определяем ключевые слова. 2. Реализуем ключевые слова как исполняемые файлы. 3. Создаём тест-кейсы. 4. Создаём скрипты. 5. Выполняем автоматизированные сценарии.
Плюсы подхода: 1) функциональные тестировщики могут планировать автоматизацию тестирования до того, как приложение будет готово; 2) тесты можно разработать без знаний программирования; 3) подход не зависит от выбранного языка программирования.
Test Driven Development
Подход разработки через тестирование (TDD) предполагает организацию автоматического тестирования посредством написания модульных, функциональных и интеграционных тестов, определяющих требования к коду перед написанием кода. То есть в первую очередь пишется тест, проверяющий корректность работы ещё ненаписанного кода. Тест, само собой, не проходит. Далее программист пишет код, где выполняются действия, необходимые для прохождения теста. Когда тест будет успешно пройден, возможна доработка имеющегося кода.
Подход Test Driven Development:
Разработка через тестирование — это больше, чем просто проверка корректности, так как она оказывает влияние и на дизайн программы. Если вы изначально сфокусированы на тестах, вам проще представить, какая именно функциональность нужна пользователю. В результате разработчик продумает детали интерфейса до его реализации. Это, в свою очередь, сократит время на разработку и отладку.
Кроме того, разработка через TDD сосредотачивается на тестировании отдельно взятых модулей, при этом используются заглушки (mock-объекты) для представления внешнего мира.
Behavior-driven development
Подход BDD — это разработка, основанная на поведении. По сути, BDD является разновидностью (расширением) TDD с той лишь разницей, что BDD-подход ориентирован на поведение сущности, которую вы тестируете (в TDD основной фокус идёт непосредственно на сам код). Суть BDD заключается в описании системы архитектуры приложения в терминах, понятных неспециалисту. Это даёт возможность ускорить процесс получения обратной связи, убрав традиционные барьеры. То есть описание пользовательских сценариев происходит на естественном языке — грубо говоря, на языке бизнеса.
Подробнее познакомиться с BDD-подходом вы сможете на курсе «Java QA Engineer» в OTUS. Образовательная программа курса включает в себя отдельный модуль, задача которого — рассмотреть и научиться применять BDD — один из наиболее востребованных на сегодняшний день подходов в автоматизации тестирования.
