Яким чином писати тести без додаткових затрат Погляд керівника команди

1. Природня і економна дорожня карта
для переходу команди розробки на
Тест центровану розробку
phpunit_tdd && mocker
Луцьк 2017

2. Для кого ця доповідь
Керівники команд
Технічні керівники
Архітектори
Бізнес аналітики
Професіонали back-end
Архітектори рішень
Менеджери проектів
DevOps із хорошою Dev частиною
*всім, кого не перераховано - срочно перепрофільовуватись!!! :)

3. Всі* ми виросли з функціонального програмування
- ми звикли мислити локальними рішеннями, а не об’єктним, бізнес
підходом.
- ми досі мислимо даними, масивами даних, а не поведінкою чи
стратегіями
- ми намагаємось вирішувати проблеми на тактичному, замість реалізації
незначних змін на стратегічному рівні
- ми думаємо, що швидкість досягається економією, але насправді
швидкість - це оптимізація процесів і підходів, а не кількості чи якості
коду.<?php
function
get_shit($input_shit) {
return $output_shit;
}
in progress...........

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

5. *
*биче гівно

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

7. Ваші розробники вже пишуть тести!!!*
Кожна команда хоч раз писала
ось такий код
Цей код - це і є зародки тестів*.
*див.: чи потрібні тести розробникам?

8. Ситуація, яка змінила все...
(с) Дмитро Данилевський 2016-2017

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

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

11. Можна,
якщо дати розробникам схожий по часу написання інструмент
*потрібно змінити функціональне мислення на
об’єктне

12. Можливість швидких точок для відладки (breakpoints)
/devel/php
drush ev
*код з devel/php одразу викидається, максимум - додається в README.md

13. Перша думка - зробіть Behat тест*
*Можна, але він буде
доходити до потрібної
точки відладки так само
довго, як і людина. А
тобто
ПО-ВІ-ЛЬНО
*в копілку міфів

14. Друга думка - PHPUnit (unit тести)
Плюси
Швидкість
Легкість відладки

15. PHPUnit (unit тести)
Мінуси
пекло setUp()
відсутні реальні дані

18. PHPUnit (unit тести)
Мінуси*
пекло setUp() - за нас вже все
робить ядро!
відсутні реальні дані - а якщо
запускати PHPUnit на
реальній базі?
*Ми створили phpunit_tdd модуль...

19. *few hours of @podarok and @danylevskyi

20. Як запустити тести - розробнику
Звичайна drush ev команда, або власна, самописна - запускає тест
~4 секунди для отримання точки зупинки IDE xdebug

21. Як запустити тести - для QA
- відкрий білд сайт (с)CIBox
- увімкни devel
- відкрий /devel/php
- запусти код
-
-
-
- результат повинен вернути посилання на сторінку

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

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

24. Демо сервісу mocker
Тільки якщо є час
Посилання на код
http://bit.ly/mocker_config_mvp
http://bit.ly/mocker_mock_service_factory
http://bit.ly/mocker_decoration
Завдання: опублікувати на drupal.org

25. Демо тестів phpunit_tdd
Тільки якщо є час
Посилання на код
http://bit.ly/phpunit_tdd_drush_runner
http://bit.ly/phpunit_tdd_test_runner
http://bit.ly/phpunit_tdd_tests
Завдання: опублікувати на drupal.org

26. Книга, яка варта уваги в контексті доповіді*
http://bit.ly/думай_як_фрік
*так, книги все ще друкуються і деякі навіть варті до прочитання

27. Запитання
http://dgo.to/@podarok
Андрій Поданенко
SW/HW Architect, FFW
Group Lead, FFW
drupal.ua mentor