Няма код? Няма проблем — Пишете тестове на обикновен английски
Как използваме Развитие, управлявано от поведение, за по-добро сътрудничество
От NAIDELE MANJUNATH и OLIVIER DE MEULDER
Разработка, управлявана от поведението, или BDD, е подход към разработката на софтуер, при който поведението на функция се дефинира чрез примери в обикновен текст. Тези примери, известни като файлове с функции, се дефинират преди началото на разработката и се използват като критерии за приемане на нови функции. Написани на езика Gherkin, който използва английски думи, файловете с функции са четими за всеки, независимо от уменията за програмиране. Файловете с функции са написани в стил „управляван от поведението“, което означава, че съдържат подробности за това как дадена функция трябва да се държи, когато нещо се случи в дадена ситуация. Това поведение е единствената информация, която се споменава във файла с функции; не се споменават основните подробности за изпълнението на функцията.
Нашият многофункционален екип — екипът за технологии за грижа за клиентите в The New York Times — използва файлове с функции, за да води по-задълбочени разговори за нашия продукт, което спомага за създаването на споделено разбиране за това какво трябва да се разработи. Когато всички разбират нашите потребителски истории, губим по-малко време в производствения процес и имаме по-малко случаи, в които преработваме работата, която сме свършили. Съвместното писане на файлове с функции насърчава сътрудничеството и помага на разработчиците и QA да разберат бизнес аспектите на историята.
Тъй като всеки от екипа може да чете и пише файлове с функции, не е необходимо да разчитаме на тестери или QA инженери, за да напишат тестовете.
Нашият процес
В началото на всеки спринт нашият продуктов мениджър пише потребителските истории за всяка функция, следвайки принципите на Agile. Ето прост пример за потребителска история, която можем да включим в един от нашите спринтове:
Като защитник на грижата за клиентите искам да актуализирам записаната кредитна карта на клиента, така че новата кредитна карта на клиента да бъде таксувана по време на следващия цикъл на фактуриране.
Когато потребителските истории са написани, нашият продуктов мениджър и нашите разработчици се събират, за да преведат потребителските истории във файлове с функции. Файловете с функции служат като схема за автоматизираните тестове от край до край, за чието написване са отговорни разработчиците.
Следвайки нашия пример за потребителска история по-горе, файлът с функции може да изглежда така:
Автоматизираните тестове са написани на Javascript. Всеки Given, When и Then ред във файла с функции съответства на проста функция на Javascript, а Then редът ще съдържа тестовото твърдение. Нашият екип използва библиотеката за твърдения на Mocha, webdriver.IO като инструмент за тестване и рамката на краставици, за да интерпретира тестовата функция, но всяка може да се използва. Разработчикът, който работи върху автоматизирания тест от край до край, може да изпълни теста локално на своята машина.
И тук се случва магията.
Тестовият производител анализира файла с функции, открива кои JavaScript функции да стартира и докладва обратно.
След като всички тестове от край до край преминат успешно, има още една стъпка. Рамката за тестване на BDD е интегрирана в нашия тръбопровод за непрекъсната интеграция (CI). Това позволява на всеки да провери дали тестовете се изпълняват в промежутъчната среда.
Докладът от теста може да изглежда така:
Както можете да видите, докладът е лесен за четене, дори и да нямате техническа подготовка.
И така, какво прави BDD полезно? Нашият екип е видял четири осезаеми ползи:
Засилено сътрудничество. Продуктовият мениджър участва в проектирането на тестовете, което означава, че те работят с разработчиците (и QA, ако е приложимо), за да формулират ясно бизнес правилата. Всеки от екипа има добро разбиране за новите характеристики на продукта и напредъкът на проекта е ясно видим за всеки член.
Жива документация. Тъй като файловете с функции служат за проверки, преди характеристиките да достигнат до производство, те трябва да се поддържат актуализирани. Всички модификации на продукта или функциите означават, че файловете трябва да бъдат актуализирани, за да се избегнат повреди, причинени от дефинициите на функциите. Въпреки че документацията често е последваща мисъл в разработката на софтуер, BDD я прави неразделна част от процеса на разработка.
Бързо нарастване. Кодът не е смислен за всички. Освен това не прави добра документация. Работата с членове на екипа, които не разбират кода, обикновено означава, че екипът трябва да създаде отделен документ, като електронна таблица, за да опише какво се покрива от тестовия код. BDD помага за решаването на този проблем с файлове с функции. Новодошлите в екипа могат да четат файлове с функции и бързо да разберат какво прави функцията. Това е по-добре, отколкото да разглеждате тонове документация.
Четливи отчети. Обикновено резултатите от теста не се представят в удобен за потребителя формат — регистрационният файл в отчета може да каже нещо загадъчно като „очаква се невярно да е равно на истина“. Въпреки че това може да е лесно за четене, контекстът или значението не са ясни за читателя: какво се очакваше да е вярно, а сега е невярно? При резултатите от BDD всеки резултат попада в съответния сценарий във файла с функции на BDD, което осигурява по-добра четливост.
Нашият екип започна да използва BDD преди няколко месеца. В началото беше малко плашещо и поразително, защото всеки трябваше да научи ново техническо умение и да работи заедно по нов начин. С течение на времето екипът усвои BDD тестването и установи, че тясната съвместна работа е много естествен процес. Когато екипът си сътрудничи върху файлове с функции, ние сме по-съобразени с цикъла на разработка и продуктът става по-добър.
Naidele Manjunath е софтуерен инженер в екипа за автоматизация на тестовете на New York Times.
Olivier De Meulder е инженерен мениджър в The New York Times Subscription Platforms Group.
