Підходи до розробки/тестування (... - driven development/testing)
Тут і там можна зустріти згадки різних підходів до розробки та тестування на основі чогось, тут короткий опис найчастіших варіантів:
TDD - Test Driven Development : розробка на основі тестів ґрунтується на повторенні коротких циклів розробки: спочатку пишеться тест, що покриває бажану зміну, потім пишеться програмний код, який реалізує бажану поведінку системи та дозволить пройти написаний тест. Потім проводиться рефакторинг написаного коду із постійною перевіркою проходження тестів. Є два рівні TDD:
Acceptance TDD (ATDD): Ви пишете один приймальний тест. Цей тест відповідає вимогам специфікації або задовольняє поведінці системи. Після цього пишете достатньо виробничого/функціонального коду, щоб виконати цей приймальний тест. Приймальний тест фокусується на загальній поведінці системи. ATDD також відомий як BDD – Behavior Driven Development;
Developer TDD: ви пишете один тест розробника, тобто модульний тест, а потім просто достатньо виробничого коду для виконання цього тесту. Модульне тестування фокусується на кожній невеликій функціональності системи. Це називається просто TDD. Основна мета ATDD і TDD - визначити докладні, здійсненні вимоги для рішення точно вчасно (JIT). JIT означає ухвалення до уваги лише тих вимог, які необхідні у системі, що підвищує ефективність.
BDD - Behaviour Driven Development: це технологія, заснована на описі поведінки. Певна людина(або люди) пише опис виду "я як користувач хочу коли натиснули кнопку пуск тоді показувалося меню як на картинці" (там є спеціально виділені ключові слова). Програмісти давно написали спеціальні тули, які подібні описи переводять у тести (іноді зовсім прозоро для програміста). А далі – класична розробка з тестами (TDD);
TDD - Type Driven Development: при розробці на основі типів ваші типи даних та сигнатури типів є специфікацією програми. Типи також є формою документації, яка гарантовано оновлюється. Типи являють собою невеликі контрольні точки, завдяки яким ми отримуємо безліч міні-тестів по всьому нашому додатку;
DDD - Domain Driven Design: Предметно-орієнтоване проектування не є конкретною технологією або методологією. DDD – це набір правил, які дозволяють приймати правильні проектні рішення. Це набір принципів та схем, спрямованих на створення оптимальних систем об'єктів. p align="justify"> Процес розробки зводиться до створення програмних абстракцій, які називаються моделями предметних областей. У ці моделі входить бізнес-логіка, що встановлює зв'язок між реальними умовами застосування продукту і кодом;
FDD - Features Driven Development: є спробою об'єднати найбільш визнані в індустрії розробки програмного забезпечення методики, що приймають за основу важливу для замовника функціональність (властивості) програмного забезпечення, що розробляється. Основною метою даної методології є розробка реального, працюючого програмного забезпечення систематично у встановлені терміни;
MDD – Model Driven Development: розробка, керована моделями – це стиль розробки програмного забезпечення, коли моделі стають основними артефактами розробки, з яких генерується код та інші артефакти;
PDD - Panic Driven Development: це своєрідний антипаттерн розробки, який, на жаль, ми постійно практикуємо. По суті це те, що виходить, коли процеси погано налагоджені і команда імпровізує в умовах палаючих термінів (нові завдання пріоритетніші за старі, код вирішує конкретні термінові завдання, але накопичується технічний борг, тестування в кінці і т.д.);
ADD - API Driven Development: розробка на основі API - це практика спочатку проектування та створення API, а потім створення на їх основі решти програми;
BDT - Behavior Driven Testing : у тестуванні на основі поведінки ваші тести засновані на user stories, які описують деякі конкретні очікувані дії програми. Замість перевірки деталей реалізації ви фактично перевіряєте те, що найважливіше: чи правильно додаток виконує user stories. Ще однією перевагою є зрозумілість тестів для менеджерів, аналітиків тощо;
MDT - Model Driven Testing : Тестування на основі моделей - це метод тестування чорної скриньки, при якому поведінка програмного забезпечення, що тестується, під час виконання перевіряється на основі прогнозів, зроблених моделями. Модель – це опис поведінки системи. Поведінка може бути описана у вигляді наочної схеми, Data Flow, Control Flow, Dependency Graphs, Decision Tables, State transition machines або mind map. Простою аналогією моделі в тестуванні є електрична схема розробки електроприладу. Цей підхід до тестування потрібний, коли висока ціна помилки у великому продукті і потрібно якомога раніше спробувати її запобігти;
DDT - Data Driven Testing (Табель-driven testing або parameterized testing): у тестуванні на основі даних тестові дані зберігаються у вигляді таблиці. Воно дозволяє одним скриптом виконувати тести для всіх тестових даних з таблиці та очікувати на результати тесту в тій же таблиці;
VDT – Value Driven Testing: тестування на основі цінності – це підхід, в основі якого лежить аналіз цінності та економічної доцільності тестування.
Джерела:
Дод. матеріал:
Last updated