Автотестування великих веб-проектів: для чого і як ми пишемо автотести – Web-systems
Технології
16 Березня 2018

Автотестування великих веб-проектів: для чого і як ми пишемо автотести

Автотестування великих веб-проектів: для чого і як ми пишемо автотести

Код завжди повинен працювати коректно. Це головне правило розробника. Коли працюєш у великій команді, де кожен робить свою частину спільного проекту, важливо забезпечити узгодженість дій. Для цього ми і пишемо Автотест. Мета автотестування: забезпечити якість продукту, а також переконається в тому, що твій код не поламають. У цій статті Front-end розробник Віталій розповідає про автотестування на одному з його проектів.

Код завжди повинен працювати коректно. Це головне правило розробника. Коли працюєш у великій команді, де кожен робить свою частину спільного проекту, важливо забезпечити узгодженість дій. Для цього ми й пишемо автотести. Мета автотестування: забезпечити якість продукту, а також впевнитися в тому, що твій код не зламають. У цій статті Front-end розробник Віталій розповідає про автотестування на одному з його проектів.

Віталій, Front-end розробник Web-Systems Solutions

У автотестів багато переваг, особливо, якщо мова йде про застосування автотестування на великих проектах. Вони працюють швидше, ніж людина, можуть виконуватися вночі й навіть на вихідних: не вимагають людського контролю, повідомлення про помилки приходять на пошту. Автотести досить точні, якщо автотестування пройшло успішно, значить коду можна довіряти. А ще вони не дають поламати ваш код вашим колегам.

Для того, щоб говорити про автотестування більш предметно, я розповім про один з наших веб-проектів, де ми пишемо такі тести. Спочатку поговоримо про саме автотестування на проекті, з легальних причин далі будемо називати його проект A, а потім поясню, як автотести впровадити в continuous integration (CI).

Як реалізовано автотестування на проекті

Автотестування у нас реалізовано за допомогою такого фреймворка, як Behat. Ця бібліотека заточена спеціально під Behaviour driving development, або BDD. Суть “ідеології” BDD у тому, що сценарії, описані зрозумілою людині мовою, не обов’язково англійською – називається вона Gherkin – переводяться в тести, з якими працює фреймворк, в даному випадку Behat. Мета синтаксису мови Gherkin в тому, щоб дати можливість нетехнічним фахівцям описати вимоги до роботи продукту.

На кожен окремий тест кейс пишеться свій сценарій за принципом “given-when-and-then” (що маємо-якщо-і-тоді). Це робиться для того, щоб потім ми могли прочитати ці тести й краще зрозуміти, як працює система. Ми можемо дати клієнту, замовнику або його менеджеру, цей так званий план “given-when-and-then”, щоб він описав своє бачення завдання. Припустимо ми робимо авторизацію на сайті і будемо писати автотест на валідацію форми. Сценарій для автотестування буде таким:

Feature: Sign up (Назва: авторизація)
Scenario: Check validation (Сценарій: перевірка валідації)
Given I am on the sign up page (Що маємо: я перебуваю на сторінці реєстрації)
When I fill in the “E-mail” field (Коли я заповнюю поле “E-mail”)
And I do not fill in the “Password” field (І не заповнюю поле “Пароль”)
Then I see an indicator of validation error (Я бачу індикатор помилки валідації)

По суті за допомогою тестування ми імітуємо взаємодію користувача з майбутнім веб-продуктом і локалізуємо помилки, якщо такі є. Фреймворк Behat обробляє те, що написано людською мовою. Він читає текст і шукає збіги в певних файлах за ключовими словами. Знаходить тест кейс, і проганяє код через автотестування. Програміст, у свою чергу, використовує цей фреймворк, щоб під кейс, написаний людською мовою, написати програмний код, який буде виконувати ці тести.

Як інтегрувати автотестування в Continuous Integration

Блог - Автотестування великих веб-проектів: для чого і як ми пишемо автотести : image-Що таке continuous integration tools і для чого вони потрібні? Існує багато інструментів безперервної інтеграції. Безпосередньо на проекті A ми використовуємо Circleci. У нашому випадку, ми використовуємо цю програму, щоб стежити за вихідним кодом. Всі зміни ми заливаємо на git-репозиторій. Коли в проекті з’являються зміни, програма автоматично білдить їх і проганяє через тести. У разі виявлення помилки, вона сповіщає нас про це. В першу чергу програма попереджає розробника, який останнім вносив зміни в код. На пошту йому прилітає сповіщення про те, де сталася помилка, що стало її причиною, і він швидко її виправляє. На продакшн сервер такі зміни не потраплять. Якщо автотестування пройшло успішно, вона відправляє зміни на продакшн.

Автотестування – хороше рішення для великих проектів, оскільки, по-перше, прискорює процес тестування і виправлення помилок в коді, а, по-друге, допомагає автоматизувати деяку роботу розробників, узгодити дії команди. Весь проект автотестами ми не покриваємо. На великому проекті може бути тисяча різних тестових сценаріїв. Природно, що автоматизувати їх всі не вийде. Є моменти, які просто краще перевіряти вручну. Взагалі мануальне й автотестування доповнюють один одного. І, якщо на проекті ви використовуєте цих два методи, можете бути впевнені, що в результаті ви отримаєте якісний продукт.

Перегляди : 287

Також рекомендуємо:

Все більше відвідувачів заходять в інтернет з мобільних пристроїв. У кафе, транспорті або на прогулянці - смартфон постійний супутник сучасної людини. Якщо ви хочете, щоб ваша продукція була під рукою в потенційних покупців, варто подбати про доступність веб-ресурсу з мобільного пристрою. Наступний крок після адаптивного дизайну - мобільна версія. У статті розберемося, чому великі бренди, крім адаптиву також мають мобільну версію сайту.
15 Червня 2017
Web-Systems Solutions використовує cookie для персоналізації сервісів і аналітики користувачів. Продовжуючи використовувати даний сайт, ви підтверджуєте свою згоду на використання файлів cookie. Ми серйозно відносимось до захисту персональних даних - ознайомтеся з умовами та принципами їх обробки.
Я погоджуюсь