Трябва ли всички правила за валидиране да се тестват в рамките на функция Cucumber?

В Ruby on Rails, ако всички правила за валидиране за даден модел се тестват в рамките на спецификацията на този модел (или единични тестове), все още ли се счита за необходимо да се напише Cucumber сценарий за всяко валидиране?

Ще бъде ли достатъчно вместо това да напишем два сценария: един за въвеждане на валидни данни и един за въвеждане на невалидни данни?


person Community    schedule 07.05.2011    source източник
comment
Извинявам се, ако това е глупав въпрос - все още се опитвам да си обмисля BDD.   -  person    schedule 07.05.2011
comment
Споделям вашата гледна точка: сценарият с две краставици е достатъчен във вашия случай.   -  person apneadiving    schedule 07.05.2011
comment
@apneadiving: Но помислете за ситуацията, ако създавате сайт за електронна търговия на едро, където клиент трябва да поръча най-малко 10 единици от всеки артикул. Това валидиране е важно бизнес правило и трябва да бъде изложено на ниво Cucumber.   -  person Andy Waite    schedule 07.05.2011
comment
@andy: определено си прав, случаят, който представяш, се нуждае от интеграционно тестване.   -  person apneadiving    schedule 07.05.2011


Отговори (3)


Това е добър въпрос и отговорът е: Зависи.

Можете да мислите за Cucumber като начин за комуникация между собственика на продукта, разработчиците и тестерите.

Ако смятате, че наличието на валидации в Cucumber допринася за споделеното разбиране за това какво прави продуктът, тогава ги запазете там.

Един подход е да комбинирате валидациите в схема на сценарий:

Scenario Outline: User tries to register but skips a mandatory field
  Given I am registering
  And I leave the "<field>" blank 
  When I click "Submit"
  Then I should see "<message>"
  And I should not be registered
    | field         | message                         |
    | Forename      | Please enter your forename      |
    | Surname       | Please enter your surname       |
    | Date of Birth | Please enter your date of birth | 
person Andy Waite    schedule 07.05.2011
comment
Това изглежда като добър компромис. Но какво ще кажете за различните типове валидации (уникалност, дължина и т.н.) Ще имам ли нужда от различен сценарий за всеки тип? - person ; 07.05.2011
comment
Трудно е да се каже без да се знае контекста. Можете ли да дадете пример? - person Andy Waite; 07.05.2011
comment
Какво ще кажете за потребителски модел, при който потребителското име трябва да е уникално и да съдържа само буквено-цифрови знаци, паролата трябва да е дълга поне 6 знака и имейл адресът трябва да е валиден. Моето мислене е, че тъй като валидациите вече се тестват в спецификацията на модела, би трябвало да е достатъчно просто да се тестват двата възможни резултата в действието за създаване на контролера в рамките на функциите на Cucumber - а именно, когато моделът се записва успешно и когато не . - person ; 07.05.2011
comment
Или може би напълно пропускам смисъла на Краставицата - това също е възможно :P - person ; 07.05.2011
comment
Добре, нека вземем примера с паролата. Вашият собственик на продукта интересува ли се дали минималната дължина е 5 знака или 6 знака? Бих подозирал, че не. За него важното е, че не е лесно да се познае или хакне. Решението за минималната дължина на паролата вероятно трябва да бъде взето от програмиста, тъй като той ще има знанията и опита да избере подходяща минимална дължина. Така че минималната дължина на паролата вероятно не трябва да бъде изложена в функцията на Cucumber. - person Andy Waite; 07.05.2011
comment
@Andy Waite: Това е много добра гледна точка. Тогава изглежда, че повечето валидации трябва да останат в спецификацията на модела. Благодаря много за вашия принос. - person ; 07.05.2011

Това е страхотен въпрос, с който се занимавам наскоро.

Може да е различно за вашата организация, но в моята организация се опитваме да оставим тестовете за проверка на място на тестовете за модули или някаква друга рамка, която се справя по-добре с тези ситуации. Освен това, аз съм от школата на мисълта, че Cucumber е предназначен само за автоматизирано тестване за приемане (известен още като инструмент за комуникация между вас/вашия екип и PO) -- и че други методи трябва да се използват за всичко извън този обхват.

person Tyler Poland    schedule 08.05.2014

Защо да оставите нещо отворено за предложения? Допускането на предположения, направени от разработчиците, е по своята същност рисковано от гледна точка на генериране на преработка.

Как всяко поле на формуляр се държи при различни обстоятелства (създаване, показване, редактиране, личност) е ясно критерии за приемане.

Ако го скриете в единичен тест, тогава го изключвате от живата документация

Наистина не би трябвало да имате нужда от модулни тестове, ако наистина сте склонни към BDD начина.

Feature: Edit staff personal
  Scenario Outline: Form validation
    Given I am editing a staff personal details
    And the form contains a "<Mandatory?>" field with a label "<Label>"
    And text fields have a input length of between "<Min Length>" and "<Max Length>"
    And select fields have these "<Options>"
    When I submit the form by clicking the save button
    Then an error displays if validation fails
    But commits my changes if validation is successful and returns the form back to display mode
    Examples:
    | Label | Mandatory? | Type | Min length | Max length | Options
    | Title | true | select | 0 | 0 | Mr, Mrs, Miss, Ms, Dr, Prof |
    | Surname | true | text | 2 | 50 | null |
    | Forename | true | text | 2 | 50 | null |
    | Known as / Other Surname | false | text | 2 | 50 | null |
    | Known as forename | false | text | 2 | 50 | null |
    | Date of birth | true | date-picker | 0 | 0 | null |
    | NI number | true | ni-number | 0 | 0 | null |
person jenson-button-event    schedule 21.01.2020