Керівництво по тестуванню додатків на Rails
Це керівництво розкриває вбудовані в Rails механізми для тестування вашої програми.
Після його прочитання, ви дізнаєтеся:
- Про термінології тестування Rails.
- Як писати юніт-, функціональні, інтеграційні та системні тести для вашого застосування.
- Про інших популярних підходах до тестування і плагінах.
1. Навіщо писати тести для вашого застосування на Rails?
Rails пропонує писати тести дуже просто. Коли ви створюєте свої моделі і контролери, він починає створювати скелет тестового коду.
Запуск тестів Rails дозволяє переконатися, що ваш код дотримується потрібної функціональності навіть після великої переробки коду.
Тести Rails також можуть симулювати запити браузера, таким чином, можна тестувати відгук свого застосування без необхідності тестування з використанням браузера.
2. Введення в тестування
Підтримка тестування вбудована в Rails з самого початку. І це не було так: "О! Давайте внесемо підтримку запуску тестів, це ново і круто!"
2.1. Налаштування Rails для тестування з нуля
Rails створює директорію test як тільки ви створюєте проект Rails, використовуючи rails new _application_name_. Якщо подивіться список вмісту цієї папки, то побачите:
Директорії helpers. mailers і models призначені містити тести для хелперів вьюха, розсильників і моделей відповідно. Директорія controllers призначена містити тести для ваших контролерів, маршрутів і вьюха. Директорія integration призначена містити тести для взаємодії між контролерами.
Фікстура це спосіб організації тестових даних; вони знаходяться в директорії fixtures.
Також буде створена директорія jobs. як тільки перший пов'язані тест буде згенеровано.
Файл test_helper.rb містить конфігурацію за замовчуванням для ваших тестів.
application_system_test_case.rb містить настройки за замовчуванням для ваших системних тестів.
2.2. Тестова середовище розробки
За замовчуванням кожен додаток на Rails має три середовища розробки: development, test і production. База даних для кожної з них налаштовується в config / database.yml.
Схожим чином можна змінити конфігурацію середовища. В цьому випадку можна змінити тестову середу, змінюючи опції в config / environments / test.rb.
Ваші тести запускаються з RAILS_ENV = test.
2.3. Rails зустрівся з Minitest
Якщо пам'ятаєте, ми використовували команду rails generate model в керівництві Rails для початківців. Ми створили нашу першу модель, де, серед іншого, мають місце незакінчені тести в папці test:
Незавершений тест за замовчуванням в test / models / article_test.rb виглядає так:
Порядкове вивчення цього файлу допоможе орієнтуватися в коді тестування і термінології Rails.
Вимагаючи цей файл, завантажується конфігурація за замовчуванням test_helper.rb для запуску наших тестів. Ми будемо включати цей рядок в усі написані тести, таким чином, всі методи, додані в цей файл, будуть доступні у всіх наших тестах.
Клас ArticleTest визначає тестовий випадок. оскільки він успадкований від ActiveSupport :: TestCase. Тому ArticleTest має всі методи, доступні в ActiveSupport :: TestCase. Пізніше в цьому керівництві ми побачимо деякі з методів, які він нам дає.
Будь-який метод, визначений в класі, успадкованому від Minitest :: Test (який є суперкласом для ActiveSupport :: TestCase), що починається з test_ (чутливе до регістру), просто викликає тест. Таким чином, методи, визначені як test_password і test_valid_password. це правильні імена тестів, і запустяться автоматично при запуску тестового випадку.
Rails також додає метод test. який приймає ім'я тесту і блок. Він генерує звичайний тест MiniTest :: Unit з ім'ям методу, який починається з test_. тому можна не турбуватися про іменування методів, а просто писати так:
Це є приблизно тим же, як якщо б написали:
Хоча ви все ще можете використовувати звичайні визначення методів, використання макросу test дозволяє отримати більш читається ім'я тесту.
Ім'я методу генерується, замінюючи прогалини на підкреслення. Хоча результат не повинен бути дійсним ідентифікатором Ruby, ім'я може містити знаки пунктуації тощо Це пов'язано з тим, що в Ruby технічно будь-який рядок може бути ім'ям методу. Це може зажадати, щоб виклики define_method і send функціонували правильно, але формально є тільки невелике обмеження на ім'я.
Далі подивимося на наше перше твердження:
Затвердження (assertion) - це рядок коду, яка обчислює об'єкт (або вираз) для очікуваних результатів. Наприклад, твердження може перевірити:
- чи є це значення рівним тому значенням?
- чи є цей об'єкт nil.
- викликає ця строчка коду виняток?
- чи є пароль користувача більше, ніж 5 символів?
Кожен тест повинен містити одне або більше тверджень, без обмежень на їх максимальну кількість. Тільки коли всі твердження успішні, тест проходить.
2.3.1. Ваш перший падаючий тест
Щоб побачити, як повідомляється провал тесту, ви можете додати провалюється тест в тестовий випадок article_test.rb.
Давайте запустимо тільки що доданий тест (де 6 - це номер рядка, де визначено тест).
В результаті F позначає провал. Можете побачити відповідну трасування під Failure разом з ім'ям провалився тесту. Наступні кілька рядків містять трасування стека, потім повідомлення, де згадано фактичне значення і очікуване в утвердженні значення. За замовчуванням повідомлення для затвердження надає достатньо інформації, щоб допомогти виявити помилку. Щоб зробити повідомлення про провал для затвердження більш читабельним, кожне твердження надає опціональний параметр для повідомлення, як показано тут:
Запуск цього тесту покаже більш доброзичливе повідомлення для затвердження:
Тепер, щоб цей тест пройшов, можна додати валідацію на рівні моделі для поля title.
Тепер тест пройде. Давайте переконаємося в цьому, запустивши його знову:
Тепер, якщо ви помітили, ми спочатку написали провальний тест для бажаної функціональності, потім ми написали деякий код, який додає функціональність, і, нарешті, ми переконалися, що наш тест пройшов. Цей підхід до розробки програмного забезпечення називають Розробка через тестування, Test-Driven Development (TDD).
2.3.2. Як виглядає помилка
Щоб побачити, як повідомляється про помилку, ось тест, що містить помилку:
Тепер ви побачите трохи більше результату в консолі від запуску тестів:
Відзначте 'E' в результаті. Вона зазначає тест з помилкою.
Запуск кожного тестового методу зупиняється, як тільки виникають будь-які помилки або провал затвердження, і тестовий набір триває з наступного методу. Всі тестові методи запускаються у випадковому порядку. Для настройки порядку тестування може бути використана опція config.active_support.test_order.
Коли тест провалюється, вам показується відповідний бектрейс. За замовчуванням Rails фільтрує цей бектрейс і друкує тільки рядки, що відносяться до вашого додатком. Це усуває шум від фреймворка і допомагає сфокусуватися на вашому коді. Однак, бувають ситуації, коли вам захочеться побачити повний бектрейс. Встановіть аргумент -b (або --backtrace) для включення цієї поведінки:
Якщо хочете, щоб цей тест пройшов, можна його змінити, використовуючи assert_raises наступним чином:
Тепер цей тест повинен пройти.
2.4. доступні затвердження
До цього моменту ви вже побачили деякі з наявних тверджень. Твердження - це робочі конячки тестування. Вони єдині, хто фактично виконує перевірки, щоб переконатися, що все працює як задумано.
Нижче представлена витримка тверджень, які ви можете використовувати з Minitest. бібліотекою тестування, використовуваної Rails за замовчуванням. Параметр [msg] - це опциональное строкове повідомлення, яке ви можете вказати для того, щоб зробити повідомлення про провал більш ясним.