Природня і економна дорожня карта для переходу команди розробки на Тест центровану розробку

phpunit_tdd && mocker

​

Луцьк 2017

Для кого ця доповідь

• Керівники команд
• Технічні керівники
• Архітектори
• Бізнес аналітики
• Професіонали back-end
• Архітектори рішень
• Менеджери проектів
• DevOps із хорошою Dev частиною
• Розробники*

*всім, кого не перераховано - срочно перепрофільовуватись!!! :)

Всі* ми виросли з функціонального програмування

• ми звикли мислити локальними рішеннями, а не об’єктним, бізнес підходом.
• ми досі мислимо даними, масивами даних, а не поведінкою чи стратегіями
• ми намагаємось вирішувати проблеми на тактичному, замість реалізації незначних змін на стратегічному рівні
• ми думаємо, що швидкість досягається економією, але насправді швидкість - це оптимізація процесів і підходів, а не кількості чи якості коду.

<?php

function get_shit($input_shit) {

return $output_shit;

}

in progress...........

Демотиватори і міфи написання тестів

• Колись будемо писати, зараз немає на це часу
• Підтримка тестів - це біль
• Тести потрібно створювати для бібліотек
• Запуск тестів - це довго
• Тести потрібно писати ідеально, або взагалі не братись за них
• Тести сповільнюють розробку
• Неможливо запускати тести на реальних даних
• Тести потрібні тільки для ядра
• Тести варто писати, якщо викладати код на d.org
• .........................

*

*биче гівно

Правильні запитання для початку

• А чи не пишуть раптом розробники вже тести під час своєї роботи?
• Чи потрібні тести для роботи розробнику?
• Чи можна пришвидшити розробку завдяки тестам?
• Чи можна запускати тести на реальних даних?
• Чи можна тестувати зовнішні живі сервіси без впливу на їх роботу?
• Що тобі заважає, щоб почати писати тести?
• Чому клієнт не хоче оплачувати написання тестів?
• Що таке ризики розробки і як ними керувати?
• Як забезпечити роботу QA силами розробників?
• Як надати можливість клієнту користуватись тестами?
• Як можна продати тести?

Ваші розробники вже пишуть тести!!!*

Кожна команда хоч раз писала

ось такий код

​

Цей код - це і є зародки тестів*.

*див.: чи потрібні тести розробникам?

Ситуація, яка змінила все...

(с) Дмитро Данилевський 2016-2017

Чи можна пришвидшити розробку з тестами?

А чи можна замінити повільні виклики швидкими?

• Стара школа

​

​

Мінуси

• Присутній код, який 100% нереально зрозуміти через місяць
• Часто цей код містить важливу інформацію (ключі, паролі)
• Не до кінця зрозуміло, який код робочий, а який - тести
• Руйнуємо принципи code coverage, коли в коді присутні частини, які насправді ніколи не виконуються.

Можна,

якщо дати розробникам схожий по часу написання інструмент

*потрібно змінити функціональне мислення на об’єктне

Можливість швидких точок для відладки (breakpoints)

• /devel/php
• drush ev

*код з devel/php одразу викидається, максимум - додається в README.md

Перша думка - зробіть Behat тест*

*Можна, але він буде доходити до потрібної точки відладки так само довго, як і людина. А тобто

ПО-ВІ-ЛЬНО

​

*в копілку міфів

Друга думка - PHPUnit (unit тести)

Плюси

• Швидкість
• Легкість відладки

PHPUnit (unit тести)

Мінуси

• пекло setUp()
• відсутні реальні дані

​

PHPUnit (unit тести)

Мінуси*

• пекло setUp() - за нас вже все робить ядро!
• відсутні реальні дані - а якщо запускати PHPUnit на реальній базі?

​

*Ми створили phpunit_tdd модуль...

*few hours of @podarok and @danylevskyi

Як запустити тести - розробнику

Звичайна drush ev команда, або власна, самописна - запускає тест

~4 секунди для отримання точки зупинки IDE xdebug

Як запустити тести - для QA

• відкрий білд сайт (с)CIBox
• увімкни devel
• відкрий /devel/php
• запусти код
• результат повинен вернути посилання на сторінку реєстрації

Як запустити тести - клієнту

• відкрий білд сайт
• увімкни модуль mocker
• перейди на форму підписки на електронні розсилки*
• внеси свою пошту client@enterprisesolutions.com
• після відправки повинен отримати повідомлення на свою електронну пошту про вдалу підписку на сайті

​

*на зовнішньому сервісі ніяких змін

Підсумок

• підміна сервісів mock() об’єктами (а не підміна даних)
• використання тестів для швидких точок входу відладки (а не для звітування про 100% test coverage)
• для розробників сайтів тести потрібні лише для швидкості і безпеки використання зовнішніх сервісів, а не для покриття всього коду
• все, що хочеться втілити в рамках команди - вже існує, потрібно лише зловити точку входу і визначити, як і в якій формі воно вже існує. І це робота Tech Lead|Architect.

Демо сервісу mocker

Тільки якщо є час

Посилання на код

• http://bit.ly/mocker_config_mvp
• http://bit.ly/mocker_mock_service_factory
• http://bit.ly/mocker_decoration

​

Завдання: опублікувати на drupal.org

Демо тестів phpunit_tdd

Тільки якщо є час

Посилання на код

• http://bit.ly/phpunit_tdd_drush_runner
• http://bit.ly/phpunit_tdd_test_runner
• http://bit.ly/phpunit_tdd_tests

​

Завдання: опублікувати на drupal.org

​

Книга, яка варта уваги в контексті доповіді*

http://bit.ly/думай_як_фрік

*так, книги все ще друкуються і деякі навіть варті до прочитання

Запитання

http://dgo.to/@podarok

​

Андрій Поданенко

• SW/HW Architect, FFW
• Group Lead, FFW
• drupal.ua mentor

​