Test driven development

Тести­ро­ва­ние ПО — это про­це­ду­ра, кото­рая поз­во­ляет под­твер­дить или опро­верг­нуть рабо­то­спо­соб­ность кода и кор­рект­ность его работы. ТПри тести­ро­ва­нии при­ло­же­нию пере­да­ются вход­ные дан­ные и запра­ши­ва­ется выпол­не­ние некой коман­ды, после чего про­из­во­дится про­верка полу­чен­ных резуль­та­тов на соот­вет­ствие эта­ло­ну, если резуль­тат соот­вет­ствует ожи­да­е­мому — тест счи­та­ется прой­ден­ным. Эта про­це­дура может быть авто­ма­ти­зи­ро­ва­на, в этом слу­чае про­верка рабо­то­спо­соб­но­сти и пра­виль­но­сти работы при­ло­же­ния осу­ществ­ля­ется гораздо быст­рее, пол­но­цен­нее и чаще (в срав­не­нии с руч­ным тести­ро­ва­нием).

Мето­дика раз­ра­ботки через тести­ро­ва­ние заклю­ча­ется в орга­ни­за­ции авто­ма­ти­че­ского тести­ро­ва­ния раз­ра­ба­ты­ва­е­мых при­ло­же­ний путем напи­са­ния модуль­ных, инте­гра­ци­он­ных и функ­ци­о­наль­ных тестов, опре­де­ля­ю­щих тре­бо­ва­ния к коду непо­сред­ственно перед напи­са­нием этого самого кода. Сна­чала пишется тест, кото­рый про­ве­ряет кор­рект­ность работы еще нена­пи­сан­ного про­грамм­ного кода. Этот тест, разу­ме­ет­ся, не про­хо­дит. После этого раз­ра­бот­чик пишет код, кото­рый выпол­няет дей­ствия, тре­бу­е­мые для про­хож­де­ния теста. После того, как тест успешно прой­ден, по необ­хо­ди­мо­сти осу­ществ­ля­ется рефак­то­ринг (дора­ботка и пере­ра­ботка) напи­сан­ного кода, при­чём рефак­то­ринг осу­ществ­ля­ется под кон­тро­лем про­хож­де­ния тестов.

Эта мето­до­ло­гия поз­во­ляет добиться создания при­год­ного для авто­ма­ти­че­ского тести­ро­ва­ния при­ло­же­ния и очень хоро­шего покры­тия кода теста­ми, так как ТЗ пере­во­дится на язык авто­ма­ти­че­ских тестов, то есть всё, что про­грамма должна делать, про­ве­ряется. Также TDD часто упро­щает про­грамм­ную реа­ли­за­цию: исклю­ча­ется избы­точ­ность реа­ли­за­ции — если ком­по­нент про­хо­дит тест, то он счи­та­ется готовым.

Архи­тек­тура про­грамм­ных про­дук­тов, раз­ра­ба­ты­ва­е­мых таким обра­зом, обычно лучше (в при­ло­же­ниях, кото­рые при­годны для авто­ма­ти­че­ского тести­ро­ва­ния, обычно очень хорошо рас­пре­де­ля­ется ответ­ствен­ность между ком­по­нентами, а выпол­ня­е­мые слож­ные про­це­дуры деком­по­зи­ро­ваны на мно­же­ство про­стых).

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

TDD (или test-driven development) — подход к разработке и тестированию, при котором сначала создаются тесты, которым должен удовлетворять код и только потом его реализация. TDD — процесс итеративный. Добавляя в класс что то новое, вы сначала пишите тест на новый функционал и только потом создаёте минимальное количество кода, реализующее нужное поведение. Ни строчкой больше, ни меньше. Добившись успешного прохождения теста, можно задуматься о качестве кода и сделать его рефакторинг.

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

BDD (или behavior-driven development) — расширение подхода TDD к разработке и тестированию, при котором особое внимание уделяется поведению системы/модуля в терминах бизнеса(заказчика). Как правило, такие тесты иллюстрируют и тестируют различные сценарии, которые интересны непосредственно клиенту системы. В связи с этим при составлении таких тестов часто используется фреймворки, обладающие синтаксисом, обеспечивающим читаемость тестов не только программистом, но и представителями заказчика:

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

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

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

К компонентным и формализующим BDD тестам уже не может быть применён итеративный подход TDD.

Сами тесты могут не быть такими атомарными и реализация, необходимая для их выполнения, не всегда тривиальна.

TDD, test-driven development или разработка через тестирование – это методология разработки ПО, в которой весь процесс разработки разбивается на короткие циклы: сначала пишется тест, проверяющий верно ли работает функционал, затем пишется код, после того, как мы добились прохождения теста, исходный код подвергается рефакторингу и снова проверяется успешность прохождения теста.

Тестирование ПО – процесс подтверждения или опровержения работоспособности кода и корректности его работы. При тестировании приложение работает с некоторыми исходными данными, после выполнения некоторой команды или другого вида обработки данных, выходные данные сравниваются с эталонными, если они совпадают – тест пройден. При автоматизации данного процесса проверка приложения будет происходить гораздо быстрее и чаще, чем при ручном тестировании.

При использовании методики разработки через тестирование сначала организуется тестирование путём написания модульных, функциональных и интеграционных тестов, которые определяют требование к коду непосредственно перед самим написанием кода. Написанный тест, естественно, не проходит и выдаёт ошибку, т.к.

самого кода ещё нет. Дальше разработчик пишет код и запускает тест, дожидаясь успешного прохождения теста. После прохождения теста исходный код рефакторится под постоянным контролем тестов.

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

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

19.01.2017AdministratorТестированиеНет комментариевtdd, методология

Добавить комментарий

Закрыть меню