природна і економна дорожня карта для переходу...

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

розробку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