Всі ми любимо нічого не робити працювати з добре документованим API. За допомогою стандартів API Blueprint або Swagger можна отримати читану машиною і людиною документацію, а значить і інструменти перевірки API на основі цієї документації.
Apiary пропонує інтерактивні інструменти для перевірки API вручну, підставляючи потрібні параметри форми, що генеруються на основі документації. Але можна отримати набагато більше користі, якщо API буде перевірятися автоматично. Це позбавляє від необхідності писати окремі тести на кожен інтерфейс, але накладає певні обмеження на структуру і якість самої документації.
image
У цьому tutorial поговоримо про утиліті Dredd на прикладі API від GitHub.
Читати далі →


Пост написаний за мотивами статті Mocking in Swift with Cuckoo by Godfrey Nolan
По боргу своєї "" мобільним розробником, постала переді мною завдання: розібратися зі створенням і використанням Моков для юніт-тестування. Моїм колегою була рекомендована бібліотека Cuckoo. Став я з нею розбиратися і ось що з цього вийшло.
Документація
Прочитавши документацію на гітхабі мені, на жаль, не вдалося "завести" Cuckoo в моєму проекті. Через CocoaPods цей фреймворк був встановлений, але от з Run-скриптом виникли проблеми: запропонований приклад не створював файл
GeneratedMocks.swift
в папці з тестами, та я б і не розібрався чому, якби не знайшов через гугл статтю, яку згадав на початку посту.

Читати далі →

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

Традиційний підхід полягає в тому, що створюється кластер БД: основна і запасна. Далі, час від часу ця БД (як правило, на Stand-By стороні) копіюється для розробників. І чим більше така БД, тим рідше вона копіюється і віддаляється і тим сильніше навантажується СГД від таких операцій. З іншого боку, розробники і тестувальники отримують застарілу БД, вона як правило місячної або навіть піврічної давності. Коли ж приходить час впроваджувати налагоджений код в продуктив, виявляється, що БД встигла сильно змінитися: з'явилися нові додаткові дані, таблиці, поля і можливо видалені старі. Це призводить до того що налагоджений код для старої БД не працює на новій, що сильно ускладнює розробку, тестування, впровадження та експлуатацію нового коду.



Читати далі →

Розробка для Sailfish OS: Тестування QML-компонентів

Доброго дня! Дана стаття є продовженням циклу статей, присвячених розробки для мобільної платформи Sailfish OS. В цей раз ми розповімо про те, як організувати тестування QML-компонентів додатків, написаних для мобільних пристроїв. Розглянемо всі етапи від написання коду до запуску тестів на реальному пристрої.

Читати далі →

Генерація фіктивних даних з Elizabeth: Частина II

image
Раніше я вже публікував статтю про те, як генерувати фіктивні дані за допомогою Elizabeth — бібліотеки для мови програмування Python. Стаття, яку ви читаєте є продовженням попередньої, тому я не буду приводити основ роботи з бібліотекою. Якщо ви пропустили статтю, полінувалися прочитати або просто не захотіли, то, ймовірно, захочете зараз, бо ця стаття передбачає, що читач вже знайомий з основами бібліотеки. У цій частині статті я буду говорити про те, яким чином організовувати генерацію фіктивних даних у власних програмах, розповім про кількох, на мій погляд, корисних особливості бібліотеки.
Читати далі →

PostgreSQL slave + btrfs і systemd = гаряча тестова база


При активній розробці, нерідко потрібна тестова база з актуальними даними з бойової бази. Добре, якщо база маленька і розгорнути копію не довго. Але якщо в базі десятки гігабайт даних і всі потрібні для повного тестування, та ще й свіжіші, то виникають труднощі. У цій статті я опишу варіант подолання подібних неприємностей з допомогою snapshot-ів btrfs. А керувати роботою отриманого комплексу буде systemd – зручний і функціональний інструмент.

Читати далі →

Об'єднуємо Code Coverage від PHPUnit і phpspec

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



Прагнути до стовідсоткового покриття коду немає ніякого сенсу, однак розуміти в середньому який відсоток коду покритий вашими тестами — хороша метрика при безперервному інтегруванні.

Ми можемо налаштувати оповіщення при падінні відсотка покриття, наприклад, нижче 50, можемо додавати автоматичні коментарі від ботів в пул реквестах, показувати тенденцію зміни Code Coverage на графіках з плином часу і т. д.

image

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

Читати далі →

Автоматизоване тестування плагінів Redmine

За минулий рік ми розробили чотири плагіна для зв'язки Redmine + Telegram раз, два, три чотири).
Потихеньку виробляються свої Best Practices щодо них. У цій замітці ми розповімо про тестування та інтеграції з Travis CI.

Чому вирішили розповісти про тестування? Тому що тестування плагіна для Redmine — той ще квест.

Читати далі →

goader — консольний бенчмарк з ухилом на запис-читання файлів

goader — консольний бенчмарк з простою конфігурацією і підтримкою різних бэкендов для тестування. Назва походить від go і loader, а також має своє значення англійською, "підганяти списом, палицею"
На даний момент можна тестувати (аргумент -requests-engine):
  • http (GET запити або GET+PUT)
  • disk
  • s3 (З авторизацією по ACCESS/SECRET keys, endpoint необхідний, але це дає можливість перевіряти private s3, signature ver4 на даний момент не підтримується, але планую)
  • null sleep для тестування самого бенчмарку
Ухил зроблений на запис та зчитування файлів сторінок
Приклад
goader -rps=300 -wps=150 -min-body-size=1 -max-body-size=128k --max-requests=1000 -requests-engine=disk -url=tmp/NN/RRRRR

image
Точки з'являються в реальному часі у відповідності з кожним запитом, мені в свій час це дозволило візуально виявити проблеми, в тому випадку, що цифри мало що дали б. У разі помилок на їх місці буде E
Існує чимало утиліт для навантажувального тестування, але особисто у мене до них ряд претензій, що і спонукало написати свій...
Читати далі →

AVA — Футуристична JavaScript бібліотека для тестування

У цій статті я хочу представити вам нову бібліотеку для тестування ВІДКРИТИ. Відносно нову, їй вже більше 2-х років, і вона обзавелася солідним кількістю плагінів і звичайно ж співтовариством що її розвиває. Ми подивимося на функціонал бібліотеки. Налаштуємо оточення і напишемо пару тестів, щоб подивитися на бібліотеку в дії.
Читати далі →