Хтось писав Юніт тести для РНР?

[peinguin]

А то в мене мало досвіду в цьому.

[Володимир Лісівка]

Ставиш PHPUnit через pear, далі пишеш стандартні автоматичні тести. Що саме не зрозуміло?

[peinguin]

та впринципі зі слова "далі". Я їх ніколи не писав.

[Володимир Лісівка]

Будь який блочний тест (який тестує блок коду) складається з:

Підготовка до тесту, якщо потрібно, у функції setUp().

Виконання блоку коду.

Перевірка результату, як правило це функції assertЩось().

Підчистка за тестами, якщо потрібно, у функції tearDown().

Якщо підготовка до тесту і підчистка за тесом не потрібні, то як правило один тест зводиться до двох рядків:

Код: [Вибрати]

function testSomething() {
  $foo=callSomething(anArgument);
  assertEqual($foo, "bar");
}
Якщо тест містить код print($foo); то це не автоматичний тест. Якшо тест не містить assertЩось(), то це взагалі не тест.

Якщо код тестів виходить значно довший наж наведений, то значить це не блочний тест а функціональний, агрегаційний, тест придатності, тест швидкої, або ще якийсь автоматичний тест. Або блок коду, який тестується, в такому випадку потрібно викинути і переписати заново з нормальним вживленням залежностей (Dependecy Injection - DI) і без побічних ефектів.

[peinguin]

А якщо код експортує записи з одного календаря в Google Calendar, то як його перевіряти?
Я не сильно розумію, коли треба писати тести, і що тестувати.

От дуже простий проект.
Треба синхронізукти календарі і ще щоб була можливість синхронізувати за розкладом.
Постійно тестую сам вручну.
Хоча, думаю, елементарний тест, що буде перевіряти роботу самописного Cron`а зробити можна.
Але уяви навіть не маю як.
З чого навіть почати.
Дякую за терпіння і розуміння.

[Володимир Лісівка]

Ну тоді це не блочні тести. Не будемо уточняти які саме це тести, щоб не відволікатися.

У такому випадку я б зробив так (якщо працює хоча б двоє розробників одночасно):

  • заніс би весь код у систему контролю версій;
  • підняв би десь Хадсона (Hudson чи Jenkins), який би при внесенні змін у код запускав мій скрипт для тесування і відсилав листа мені у випадку винекнення проблем;
  • створив би тестовий рахунок на Ґуґлі і отримав би ключ для АПІ;
  • написав би скрипт, який виконує інсталяцію коду на окремий сервер (в мене є скрипт який піднімає новий локальний віртуальний сервер з окремим ім’ям і неазйнятою айпішкою в діапазоні 127.xxx.xxx.xxx для вказаного каталогу) і запускає якійсь тестові сценарії;
  • якщо сценарій відпрацював з помилками, то Хадсон вишле листа автору останніх змін.

Тестові сценарії можуть:
  • викликати напряму АПІ сервера для тестування функціональності серверної частини;
  • виконувати у переглядачі записаний сценарій, наприклад при допозі Селена (Selenium) або якоїсь іншої системи (я зараз із Sahi знайомлюся), для тестування інтерфейсу системи. У мене десь валяється мій скрипт на баші, який вміє запускати селеновські скрипти в кількох паралельних різних переглядачах (FF, Opera, IE6 під вайном) під віртуальними іксами чи під Xvnc.

Процес розробки виглядає так (для кількох розробників):
  • робиться окрема гілка в системі контролю версій;
  • в Хадсоні робиться копія проекту, яка тестуватиме тільки мою гілку (архітектура тестів повинна підтримувати паралельне незалежне тестування);
  • пишу додаткові тести, які перевірятимуть нові зміни, далі колупаюся в коді і тестах доки все не запрацює як слід (поки Хадсон не затихне), синхронізуюся з головною гілкою і підправляю якщо щось поломалося;
  • віддаю код на перегляд і підтвердження іншому розробнику, сам займаюся якоюсь іншою проблемою в іншій гілці;
  • синхронізую мою гілку з головною, перевіряю і правлю якщо щось поламалося, вношу свої зміни в головну гілку і закриваю свою приватну гілку.

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

Щодо вашого проекту, то якщо у вас вже є сценарії тестування, то просто запишіть його покроково у коді. Для простих кроків напишіть код, для складних кроків напишіть «Зробіть бла-бла-бла і натисніть Ввід.». Коли задовбає робити ці операції вручну, то напишете скрипт для них.

Тестування кронівських скриптів досить просте — заплановуєте виконання команди на час +65с від поточного часу, чекаєте 125с (якщо скрипт виконується менше 1хв.), перевіряєте результат, видаляєте кронівський файл. Для цього потрібно мати шаблон, в який можна вставити час виконання. Я не знаю, який у вас там самописний крон, тому наведу приклад тесту на шелі для звичайного крону (не тестував):

Код: [Вибрати]

#!/bin/sh
set -u

TEST_ID="$RANDOM"
EXIT_CODE=0

# Cleanup
rm -f "/etc/cron.d/$TEST_ID.crontab"
rm -f /tmp/$TEST_ID.log


TIME=`date  --date="next minute" +%M`

echo "$TIME * * * * foo-bar >/tmp/$TEST_ID.log 2>&1" >"/etc/cron.d/$TEST_ID.crontab" <<CRONTAB

sudo service crond reload

sleep 65

[ -e "/tmp/$TEST_ID.log" ] || {
  echo "[foo-bar test] ERROR: Expected log file is not found after execution of foo-bar from cron." >&2
  EXIT_CODE=1
}

# TODO: check content of log file for errors

# Cleanup
rm -f "/etc/cron.d/$TEST_ID.crontab"
rm -f /tmp/$TEST_ID.log

exit $EXIT_CODE



[peinguin]

Як круто все виходить.
Тести це такскладно

ідея в тому, що людина заносить час виконання і повторення завдання в БД. Скрипт викликається кроном і перевіряє умови.

[Володимир Лісівка]

Як круто все виходить.
Тести це такскладно

Тестування — це одна з найпростіших частин програмування, але дуже витратна по часу. Всі ці тонкощі і хитрощі спрямовані на зменшення витраченого часу. Запустити тести не довго, але Хадсон робить це ще швидше. Можна тримати в пам’яті коли була остання робоча версія, а можна не забивати собі цим голову і створити окрему гілку. Можна руками виконувати всі кроки по сценарію кожен раз, а можна його записати в коді і не намагатися отримати RSI.

Можна відмовитися від усього цього, просто тоді тесування буде займати більше часу або виконуватиметься рідше чи в неповному обсязі, від чого страждатиме якість.

Коли програма, команда, і кількість тестів маленькі, то все це так не відчувається.  Всі ці елементи процесі добре відчуваються тоді, коли проект розростається до таких розмірів, коли команді з десятка тестерів потрібен місяць для виконання всіх ручних тестів, а вже автоматизовані тести вимагають від 2 з лишком годин для мінімального набору до 2 тижнів для повного набору усіх тестів, а нова версія програми виходить кожні два тижні.

ідея в тому, що людина заносить час виконання і повторення завдання в БД. Скрипт викликається кроном і перевіряє умови.

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