Власне тестове середовище на docker

Для чого тестеру може знадобитися свій інвайронмент, якщо можна просто почекати, доки код виллють на тестовий сервер?

Мені це питання задають постійно. І відповідь, як завжди, залежить від контексту.

Щось ризиковане треба перевірити у середовищі, яке не шкода; для чогось потрібні особливі налаштування, недоступні на тестовому сервері; а хтось, як я, хоче тестити ще у девелоперській гілці, бо не може дочекатися, доки новий код нарешті дорев’ювлять і замерджать в develop.

В епоху віртуальних машин існує кілька загальних інструментів, що дозволяють запустити собі власне тестове середовище, та заразом вижерти зайву оперативку та довантажити процесор вашого комп’ютера до "прийнятних" 104%.

Як розгорнути два зв’язаних docker-контейнера: веб-сервер із Вашим проектом та базу, подивимось на прикладі PHP та MySQL.

Що таке "добрі локатори" на web-сторінках

Писання автоматизованих тестів для web GUI складається, великою мірою, не тільки з логіки перевірок та вигадування моделі тестових даних, як під час тестування API, а ще й із прив’язування логіки тесту до правильних елементів на сторінці, тобто - побудови локаторів.
Окрім усім очевидних методів пошуку елемента за id чи ім’ям класу (class name), іноді у нагоді стають css-selector'и та xpath'и, що дозволяють вкласти певну логіку у спосіб пошуку, та значно полегшити код самої перевірки, звівши її до простої присутності елемента за зазначеним локатором. Але який локатор вважати добрим?

Як читають багрепорти?

Головною і чи не єдиною загальновживаною метрикою ефективності тестерів є кількість баг-репортів. Ну а якість цих звітів - головний результат роботи тестувальника.
Основні елементи баг-репорту приблизно однакові, незалежно від системи відстежування дефектів. Але у кожному конкретному випадку найбільш доречними для заповнення можуть бути різні поля. І, на мою думку, об’єм необхідної інформації у звіті залежить від порядку, в якому наша "цільова аудиторія" (ПО, кодер чи інші тестери) читають звіти.
Отже, як читають баг-репорт:

1. Summary

   Опис дефекту - те саме, що тема у листа. Він або викличе цікавість, і читач одразу його відкриє, щоб дізнатись деталі; або читачу стане і так все ясно.
   В Джірі (Jira) на дошці перегляду беклогу на 17’’ моніторі видно від 30 до 56 символів Summary. Цим екраном зазвичай користується ПО (Product Owner), пріоритизуючи задачі. Це не привід обмежуватись 50-ма символами. Просто треба поставити найважливішу саме для ПО інформацію на початок опису, як то: назву функціональної області чи функції, наслідки цього дефекту для функціональності.                                                                                                                  Наприклад: Player: Video played slower than Real time [приблизна межа видимості] when played from the middle

1. Screenshots

   Нотаріально завірені скріншоти - друге, на що дивиться зацікавлений описом читач. Відкривши ваш звіт, він хоче якнайшвидше переконатися, що баг таки присутній у системі, чи принаймні у тестовому середовищі. Скріншоти, тобто візуальна інформація, дуже корисні для швидкої оцінки "звинувачень".
   Я раджу вставляти їх завжди, адже функціонал може змінитися, кроки - стати не актуальними, а скріншоти - залишаться єдиними свідками колишніх "фаталів".

2. URLs

   Після швидкого перегляду візуальних доказів, наш приголомшений читач спішить-перекидається побачити усе на власні очі. Тому він швидко сканує текст звіту, шукаючи посилання, що якнайшвидше забере його туди. (Тут я згадую себе, коли мені скидають критичний баг-репорт з продакшону :-Е )
   Найчастішою відмазкою, щоб не вставляти URL-адреси є те, що, мовляв, перевіряємо на тестовому середовищі, чий вік вимірюється якщо не годинами, то днями. І за тиждень клікнувши на посилання, ви отримаєте "Server not found". Але навіть таке посилання - дуже корисне, бо насправді ім’я сервера можна легко поміняти на існуюче. Якщо Ви соромитесь вставляти неробочі URL'и, можете написати перед ним "e.g.", або вставити адресу без імені сервера.
   

3. Expected result vs. Actual result

    А поки посилання відкриваються у сусідній ўкладці, наш нетерплячий читач з’ясовує, що ж звітовник очікував на тій сторінці побачити, і у чому саме відмінність від реальності.
   

4.  Preconditions & Steps, Environment, Severity

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

TeamCity для дому та офісу

Працюючи вдома чи на невеличкому проекті, на який навіть наймолодшого адміна смикати соромно, все ж виникає бажання зробити парочку щоденних перевірок, чи то у базі даних, чи просто автотестиків, чи запуск будь-якого скрипта з командного рядка. Можна все, звичайно, руками запустити, але із своїм домашнім CI (Continuos Integration Server) було б приємніше. 

Вже маючи трохи досвіду із Jenkins'ом, можу сказати що TeamCity краще: простіше у налаштуванні, приємніший інтерфейс. Розробники з JetBrains - як завжди молодці. Є обмеження безкоштовної ліцензії, але коли ваш проект виросте за їхні межі, думаю, і девопса можна буде долучити.
Єдине, про що варто потурбуватися перед встановленням - щоб ця машина мала доступ до всіх ресурсів, які ви збираєтеся перевіряти.

Отже, тут невеличкий список кроків для запуску TeamCity на Ubuntu у домашніх умовах.