Levinumad acceptance testide loomise vahendid Behavior-Driven Development metoodikas on RSpec (Ruby jaoks) ja Cucumber (universaalsem). Olles mõlemat mõnevõrra pruukinud, tekkis küsimus, et kumb siis on lõpuks acceptance testimiseks parem. BDD põhitõdesid ei hakkaks ehk siinkohal kordama, vaataks hoopis Cucumberis ja RSpec’is testide kirjutamist hüpoteetilise Rubys kirjutatud veebirakenduse jaoks.
Mõlemad tööriistad kasutavad brauseri käitamiseks Capybara-nimelist veebirakenduste testimise raamistikku. RSpec’i ja Cucumberi erinevus seisneb peamiselt testi loetavuses ning kirjelduse nö. tasemes. Lihtne näide esmalt Cucumberi stsenaariumina:
Feature: Blog articles In order to have an awesome blog As an author I want to create and manage articles Scenario: Article index Given there are 2 articles When I go to the articles page Then I should see the following articles: | Article title | | Article one | | Article two |
Iga sammu tähenduse Cucumberile arusaadavaks tegemiseks tuleb need defineerida:
Given /there are (.*) articles/ do |number|
number.times { |n| Article.create! }
end
Nagu näha, kasutab Cucumber testide kirjeldamiseks loomulikku keelt ja seetõttu on sellised testid väga hästi loetavad, samuti aitab kõrgema taseme funktsionaalsusele keskendumine kergemini vastata küsimusele “Mida meie rakendus õigupoolest tegema pidi?“. Teisalt on antud juhul vajalik kirjutada ka sammudefinitsioonid, et Cucumber teaks, mida meie loomulikus keeles kirjeldatud stsenaariumitega peale hakata, seega tekib testidesse üks lisakiht, mis samuti vajab ülalpidamist.
RSpec seevastu tegutseb madalamal, detailsemal, tasemel. Ülaltoodud stsenaarium üks-ühele RSpec’i ümber kirjutatuna võiks välja näha umbes selline:
describe "Article index" do
it "by title" do
2.times { Article.create! }
visit articles_path
page.should have_content "Article one"
page.should have_content "Article two"
end
end
Selline test küll teeb täpselt sama, mis eeltoodud Cucumberi stsenaarium, kuid ei ole nii hästi loetav. Võtame kasutusele Capybara RSpec helperi ja kirjutame testi paremaks:
require 'capybara/rspec'
feature "Articles", %q{
In order to have an awesome blog
As an author
I want to create and manage articles
} do
background do
Article.create!(:title => 'Article one')
Article.create!(:title => 'Article two')
end
scenario "Article index" do
visit articles_path
page.should have_content('Article one')
page.should have_content('Article two')
end
end
Loetavus paranes märgatavalt ja ka test näeb üsna sarnane välja Cucumberi stsenaariumile, millel ta põhineb.
Lõpetuseks
RSpec’il on tugev eelis Ruby arendajate jaoks, kes saavad nii unit kui acceptance testid kirjutada ühe vahendiga. Cucumber jällegi võimaldab olemasolevaid teste ilma olulise lisatööta kasutada spetsifikatsiooni dokumendina, mis on ka keskmisele kliendile loetav. Ja lõppude lõpuks on testide kvaliteedi seisukohalt hoopis olulisem järgida ka testide kirjutamisel üldiseid tarkvaraarenduse häid põhimõtteid.