Чи справді варті RSpec та огірок?

Я знаю, що більшість програмістів RoR випробовують наркоманів, і я розумію переваги великого тестового набору, але коли я починаю тестувати, я ніколи не отримую такого великого набору, і мені завжди цікаво: "Чи я тестую правильний шлях? Чи є дійсно ефективні?". Я часто маю справу з тестуванням інтеграційних тестів лише тим, як поводиться додаток.

По-перше, чи дійсно варто тестування? Я маю на увазі, чи дійсно варто часу, витраченого на написання тестів?

Тоді я використовую RSpec, я нещодавно виявив огірок, деякий час використовував його, але не знаю, чи справді варто написати ці кроки? Я знаю, що можу повторно використовувати етапи, але я ніколи не знаю, чи ці кроки занадто завершені чи ні: Наприклад, я використовував, Given I am logged in as (.+)але не знаю, чи повинен я сказати у своєму визначенні, Given there's a user called $1оскільки він може дублювати користувача, якщо він коли-небудь створений але не варто завжди робити крок раніше Given I am logged in as (.+). Це досить багато коду, який може бути рідко корисним. Я здогадуюсь, що на деталях, що випробовуються щодня, немає нових помилок ... Тож огірок справді вартий порівняно з RSpec?

Моє "ах-ха!" настали моменти про тестування в Ruby and Rails, коли я справді сів і прочитав остаточні ресурси з цього питання, книги Rspec і огірок . Я поділився вашою початковою зневагою до Огірка, але потім зрозумів, що дивлюся на картину з зовсім неправильного кута.

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

Given I am logged in
And I can see the post "BDD is awesome"
When I vote the post up
Then the post should have one more vote
And the page should show a message thanking me for my vote.

Зауважте, що там немає посилань ні на що, пов'язане з кодом. Це відбувається у ваших кроках. Коли ви рефакторируете код, можливо, вам доведеться змінити свої визначення кроків, але поведінку (вашу функцію) ніколи не потрібно буде змінювати.

Тепер кожного разу, коли ви запускаєте свою функцію «Огірок», вам дуже важливо пройти тестування функції за допомогою TDD (тестова розробка). Це робиться на нижчому рівні за допомогою RSpec.

Перший запуск - визначення мого першого кроку не визначене. Скопіюйте блок, щоб визначити його в скажімо user_steps.rb або навіть session_steps.rb, оскільки він стосується користувачів та їх сеансів. Тепер, як визначити, що користувач увійшов до системи? Ви можете взяти їх через процес входу.

Given /^I am logged in$/ do
  visit login_path
  fill_in :name, :with => 'Joe'
  fill_in :password, :with => 'Password'
  click_button 'submit'
end

Повинні бути всі щасливі. Другий крок.

Given /^I can see the post "(.+)"$/ do |name|
  visit post_path(Post.find_by_name(name))
end

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

When /^I vote the post up$/ do
  pending 
end 

Ось де ви починаєте говорити про нові функціональні можливості, але ви не зовсім знаєте, як це все ще буде працювати. Як ви голосуєте за публікацію? Ви можете натиснути на зображення +1 або щось подібне, що виконує публікацію ajax до контролера, який повертає JSON або щось подібне. Тож тепер ви можете перейти до чистого тесту Rspec.

• Перевірте свій погляд, щоб переконатися, що зображення +1 відображається,
• Перевірте свій контролер на правильність поведінки, коли він отримує заданий запит ajax потрібного формату (як щасливі, так і нещасні шляхи - що робити, якщо отримано недійсний ідентифікатор повідомлення? Що станеться, якщо користувач використає свої 25 оновлень за день? Чи правильно вона збільшує кількість голосів?)
• Перевірте свій JavaScript, що він відповідає правильно, коли йому надано крапку JSON у потрібному форматі (чи оновлено зображення +1, щоб показати, що воно було використано? (Маючи на увазі Google+ тут ​​...) Чи відображається повідомлення подяки? Тощо )

Все це не впливає на поведінку - але коли ви закінчите займатися тестуванням нижчого рівня, буде неправдивим заповнити крок визначення того, як проголосувати за публікацію. Це може бути так само просто click_link '+1'. А решта кроків - це результати тестування, які знову ж таки повинні бути прості. І коли ви закінчите, то знаєте, що ваша функція завершена і закінчена. Якщо потрібна поведінка зміниться, ви можете налаштувати свою функцію, інакше ви можете налаштувати ваш код реалізації в ідеальній безпеці.

Сподіваюся, це має сенс. Це все було в моїй голові, але я думаю, що це демонструє різницю між BDD і TDD, і чому огірок і RSpec обслуговують різні потреби.

Тестування, на мою думку, - це мистецтво. Якщо ви робите TDD (використовуючи RSpec або будь-який інший фреймворк), спочатку відчувається, що ви "витрачаєте час". Це зрозуміло, оскільки ви не пишете жодного виробничого коду.

Однак ви починаєте бачити перевагу TDD, коли вам потрібно покращити свою кодову базу , гарантуючи, що все ще працює. TDD допомагає вам виявити помилки регресії якомога раніше. Це врятувало мені дні роботи, тому що у мене були зосереджені тести, які вказували на мої помилки.

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

Опинившись у розпалі TDD, все інше почувається не так.

Я вважаю, що ви прямо на огірковому фронті. Написати всі ці кроки - це багато клопоту, і користь не виправдає біль. Про шість недоліків використання огірка я писав тут багато: чому турбуватись з тестуванням огірків?

Тести для одиниць і регулярні тести на інтеграцію, які виконуються або за допомогою Rspec, або Test :: Unit, мають багато сенсу, але, на щастя, їх набагато швидше написати, ніж тести на огірок. Для одного ви можете використовувати чистий Ruby замість того, щоб боротися з багатослівним і незграбним синтаксисом Gherkin.

Я особисто вірю, що це RSpec testing is a definite must. Скажімо, наприклад, що ви хочете написати нову функцію, яка також має посилання на якусь іншу функцію, і ця функція може бути посилається на якийсь інший модуль або методи. Тож як можна переконатися, що те, що ви пишете, не порушує жодної іншої частини програми?

Припустимо, що у вас є велика програма і що ви зашифрували щось тривіальне порівняно із загальною програмою, чи повторите ви повторну перевірку всієї програми, натиснувши кожне посилання в програмі, щоб переконатися, що вона працює щоразу, коли ви змінюєте один рядок коду?

Однак я вважаю, що тестування огірків не є обов'язковим. Я думаю, що тестування інтеграції за допомогою RSpec саме по собі має більше сенсу до тих пір, поки не доведеться перевіряти тести клієнтом. Що з мого досвіду РІДНЕ. Якщо ваша команда повністю складається з розробників, я думаю, що вам слід замінити кроки огірка для тестування функцій RSpec. І я думаю, що після RSpec 3 DSL тести досить легко читаються.

Наприклад:

Визначення кроку огірка:

Given /^I am logged in$/ do
  visit login_path
  fill_in :name, :with => 'Joe'
  fill_in :password, :with => 'Password'
  click_button 'submit'
end

Тест функції RSpec:

feature 'Given the user is logged in' do
      visit login_path
      fill_in :name, :with => 'Joe'
      fill_in :password, :with => 'Password'
      click_link_or_button 'submit'
end

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

Крім цього, це також виключно ваші власні переваги.

Сподіваюся, це може допомогти вам трохи зрозуміти.

На мою думку, перш за все, це розмежувати практику та конкретні рамки. Огірок не BDD, RSpec його не TDD.

Якщо ви хочете перевірити свою систему RSpec на її хороший інструмент, ви можете зробити TDD або BDD за допомогою RSpec, адже TDD і BDD - це одне і те ж. Хтось каже "BDD його TDD зробив правильно", і я повністю згоден з цим, BDD в першу чергу щодо тестування особливостей / поведінки замість методів / класів тестування. Насправді TDD, що Кент Бек описує свої особливості, але BDD допомагає багатьом людям зрозуміти цю ключову різницю та її великий внесок від Dan North у спільноту розвитку.

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

Підсумок:

• Якщо ви хочете зробити TDD / BDD самостійно або в команді -> спробуйте RSpec
• Якщо ви хочете краще спілкуватися з бізнесом з Історіями та сценаріями користувачів -> спробуйте огірок
• Якщо ви хочете живу документацію з особливостей системи -> спробуйте огірок.

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

Але завжди пам’ятайте, що RSpec і огірок - це лише інструменти, а інструменти вирішують конкретні проблеми, яку проблему ви хочете вирішити? Будьте кращим програмістом щодо прийняття цих рішень, а не щодо використання рамки X / Y / інструмента / бібліотеки / технології.