природна і економна дорожня карта для переходу...
TRANSCRIPT
Природня і економна дорожня карта для переходу команди розробки на Тест центровану
розробку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
- перейди на форму підписки на електронні розсилки*
- внеси свою пошту [email protected]
- після відправки повинен отримати повідомлення на свою електронну пошту про вдалу підписку на сайті
*на зовнішньому сервісі ніяких змін
Підсумок
- підміна сервісів 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