Разработка, управлявана от тестове и RSpec

Когато започвате нов проект, най-естественият курс на действие може да бъде да се потопите направо и да започнете да кодирате. След известно време сте изградили някои функции на вашето приложение, наполовина сте изградили други; нищо не работи и е невъзможно да се каже в коя посока да се насочи. Със сигурност би било полезно да видите къде приложението ви се проваля, за да знаете какво има нужда от работа. Добре дошли в тестово разработка!

С две думи, разработка, управлявана от тестове (TDD) означава първо да напишете тестове и да оставите тези тестове да ръководят изграждането на вашия проект. Първото писане на тестове може да изглежда контраинтуитивно, но се отплаща, като предоставя стъпка по стъпка инструкции какво да се изгради. В крайна сметка това всъщност може да направи разработката на вашето приложение по-бърза, защото имате ясна посока.

Помислете за тази лавица за книги на Ikea:

Вероятно бихте могли да го сглобите, без да гледате инструкциите. Разбира се, почти сигурно ще излезе наяве и ще отнеме повече време, отколкото трябва. Вероятно ще счупите едно от тези дървени колчета и тогава какво? По-добре е първо да прекарате известно време в четене на инструкциите, за да сте сигурни, че го изграждате бързо и правилно. Разработката, насочена към тестове, е почти същата, с вашето приложение като мебели на Ikea и тестовете като ръководство с инструкции, което напишете сами.

Не е лошо да прекарвате МНОГО време в писане на тестове, преди да пишете код. „Защо да отделяте време и усилия за писане на допълнителни редове код, когато бихте могли да прекарате това време в действително създаване на вашето приложение?“ ти каза. Стойността е в планирането и подготовката. Колкото по-подробни са вашите тестове, толкова по-лесно и по-бързо ще бъде да завършите приложението си.

Друга причина, поради която писането на тестове е толкова полезно, е, че те ще ви кажат, когато нещо се повреди в приложението ви. Като разработчици на софтуер всички ние сме написали код, който сме смятали за здрав, който в крайна сметка се проваля безшумно. Наличието на тестове на място помага за предотвратяване на ситуации като тази и като допълнение, внедряване на повреден софтуер. След като направите промяна в кода си, изпълнете тестовете си. Ако забележите, че нещо не работи, което е работило преди, знаете, че сте направили грешка при последното нещо, което сте променили. Един тест може да ви подскаже точно защо вашата програма се счупва.

Като цяло, тестването ще ви помогне да кодирате по-добре, по-силно и по-бързо. Съществуват рамки за тестване, за да ни помогнат да пишем тестове и по-специално един, който е мощен, но лесен за научаване, е RSpec.

RSspec

За Ruby RSpecе една от най-популярните рамки за тестване. RSpec използва английски език, за да използва „разработка, управлявана от поведението“, описвайки как част от код трябва да действа заедно с очаквания резултат. Съвсем буквално, вие пишете това, което очаквате да направи кодът. Ето един пример, описващ как трябва да се държи методът .new на клас, наречен Song:

describe '.new' do 
    it 'creates a new instance of a song from the name passed in' do 
      new_instance = Song.new('Still Fly')
      expect(new_instance.name).to eq('Still Fly')
    end
  end

Първият ред представя кода за тестване, .new. Вторият ред описва какво прави .new. По-долу е частта за тестване, в която .new се използва за създаване на нов екземпляр. След това expect извиквамеnew_instance.name на равно'Still Fly'. Като написахме този тест, ние гарантирахме, че Song трябва да се инициализира с валидно име, а не нещо друго като цяло число. Няколко важни неща, които трябва да имате предвид: тестът обикновено трябва да включва само един израз expect и трябва да избягвате използването на думата „трябва“ в оператора it. Това прави вашите тестове по-ясни и конкретни.

След като RSpec бъде инсталиран, напишете тестовете за вашите Ruby файлове в свързан спецификационен файл. Горният пример тества обект Song, дефиниран във файл с име song.rb. Следователно тестовете трябва да бъдат записани във файл с име song_spec.rb и да се съхраняват в папка spec.

Файлът spec_helper.rb се генерира автоматично при инсталиране на RSpec. Той съпоставя файловете, които се тестват, към файловете със спецификации. Не забравяйте да изисквате файловете, които искате да тествате, в горната част на spec_helper.rb.

Изпълнението на rspec в командния ред ще ви покаже всички преминали и неуспешни тестове. Мисля за това като за списък със задачи, които се нуждаят от работа. Това е пътната карта за разработване на вашето приложение и използването на RSpec го прави доста безболезнено.

Жасмин

Не сте рубист? Не се притеснявай. Подобни рамки за тестване на RSpec съществуват за други езици. За Node и Python вижте Jasmine(забележка: има и скъпоценен камък Jasmine за Ruby). Беше силно повлиян от RSpec и всъщност настройката и синтаксисът са почти същите. Тестовете се съхраняват в спецификационни файлове в папка spec точно както в RSpec. Тестовете използват същото многословие като в RSpec. По-долу е същият тест като по-горе, написан за Jasmine в JavaScript:

describe('.new', function() {
  it('creates a new instance of a song from the name passed in',      function() {
    var newInstance = new Song('Still Fly')
    expect(newInstance.name).toBe('Still Fly');
  });
});

Доста подобни! Основната структура на RSpec се отнася и за Jasmine.

Разработката, насочена към тестове, е чудесен начин да гарантирате, че вашият код остава възможно най-без грешки. RSpec и Jasmine са прости, мощни инструменти, които биха били полезни за всеки, който използва TDD. В мрежата има отлични ресурси за писане на тестове и в двете рамки. За повече информация относно етикета на RSpec вижте http://www.betterspecs.org/. За да разгледате по-подробно Jasmine, вижте https://jasmine.github.io/2.1/introduction.

Разработка, управлявана от тестове и RSpec

RSspec

Жасмин

Подобни въпроси