Acceptance tests

[Evgeni Dzhelyov]

Някой може ли да сподели информация (книга, видео, блогове, личен
опит)
как да се подходи към дефинирането и писането на acceptance тестове.

Само при наличието на UI ли дефинираме acceptance тест ?
Ако ни е възложено да напишем отделен модул, по-какъв начин можем да
дефинираме public API-то,
удачно ли е да се изпозват acceptance test, в такъв случай ?

[Hristo Koshev]

On 08/25/2011 01:37 PM, Evgeni Dzhelyov wrote:
> acceptance test
Zdravei,

Pregladai tova ... http://cukes.info/

Ako imash vuprosi pishi .... tova e po skoro pulna concepcia za
izgrajdane spored zadedeni kriterii ...

Pozdravi,
Hristo Kochev

[Hristo Deshev]

Здравей Евгени,

Може би първо трябва да си изясним какво имаш предвид АТ и за какво ти трябва. Имаш ли product owner(PO), с който си обсъждате историите и дефинирате тестове за "успех" на всяка история? Ако да, то има смисъл да проучиш някой инструмент за писането на тези тестове на по-високо ниво така, че въпросният човек поне да може да ги разчита. Чувам, че Fit/Fitnesse и Cucumber са интересни инструменти. Сигурно има и други. Нямаш PO? Какво искаш да постигнеш с тези тестове? Имаш ли вече unit tests?

Ако нямаш PO, можеш да си разпишеш тестове на каквото на теб ти е удобно, за да упражниш цялата функционалност в историята. Хубаво е да кажеш и какъв проект правиш. При десктоп приложение играта е една, при уеб, друга, а има и още случаи. За пример, имал съм АТ на приложение, което показва REST API в уеба с моя самоделка, която правеше нужните HTTP заявки. Удобно е като "потребителския ти интерфейс" се парсва лесно с JSON парсър нали :-)

2011/8/25 Evgeni Dzhelyov <evgeni....@gmail.com>

...

Само при наличието на UI ли дефинираме acceptance тест ?

Често срещана заблуда е, че АТ трябва да минават през потребителският интерфейс. Аз даже бих препоръчал, ако може, да се избягва, защото това винаги носи неочаквани усложнения.

 

Ако ни е възложено да напишем отделен модул, по-какъв начин можем да
дефинираме public API-то,
удачно ли е да се изпозват acceptance test, в такъв случай ?

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

Поздрави,

Христо

[Evgeni Dzhelyov]

Под АТ разбирам тест, който описва фунциалността от PO гледна точка,
може да послужи като документация
за използване на системата и се изпълняват в среда близка до
production. И като цяло тестват изцяло или
близко до end-to-end. Тези тестове веднъж минаващи не трябва да
фейлват, а ако това стане е сигнал за
regression.

Аз работя с уеб неща и там има доста инфо и технологии как да ги
напишеш, дали ще минеш през GUI, дали няма да минеш
и т.н.
Мен ме интересува, дали някой подхожда към други проблеми, които са
много по-ограничени и са ориентирани към решаване на определени
програмистки проблеми.
Примерно подхванал съм да решавам разни задачи от puzzlenode.com, като
идеята ми е да тренирам TDD подход.
Самите проблеми са доста малки, взимат някакъв текст за вход и връщат
друг текст за изход. И АТ които пиша за тях са нещо
от рода на:

test 'solve simple case' do
fixture = load 'simple_case.input'
expected = load 'simple_case.output'

answer = Solver.new fixture

assert answer, expected
end

test 'solve more complicated case' do
...
end

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

В момента чета 'Growing object oriented software guided by tests' и
това е първата книга в която различните тестове са ясно разделени и
описани.
Гледах това видео[1] на Yehuda Katz, където обяснява как всичките
тестове, които са имали в merb 0.5 не са им вършили никаква работа за
refactoring
и затова са написали нови които директно минават през public API-то им.

Но това са единствените материали, до които имам достъп, които
обяснавят нещата в дълбочина и дават точни примерни. Всичко останало е
какъв е синтаксиса
на еди кой си xUnit, как unit тестовете работели или не работили,
cucumber-ския Gherkin и т.н.

Някой знае ли подобни материали или собствен опит, които да сподели.
Примерно, сега ми се налага да бачкам с някакво конзолно приложение и
се чудя как да го тествам ?
Мога да напиша тестове които го стартират, подават му различни
аргументи и да гледам после резултата, примерно да пренасоча STDOUT и
STDERR и да ги прегледам, дали
са очакваните. Или пък мога да видя какви точно методи се викат, като
се извика bin-a и да тествам тях, но тези тестове не ми казват, че
всъщност реално bin-a работи както се очаква.
Тогава какви тестове трябват за да потвърдят, че и bin-a работи правилно ?

Поздрави,
Евгени

[1] http://rubyconf2008.confreaks.com/writing-code-that-doesnt-suck.html

[Hristo Deshev]

2011/9/2 Evgeni Dzhelyov <evgeni....@gmail.com>

...

Някой знае ли подобни материали или собствен опит, които да сподели.

Мога да препоръчам една "старичка" книга на Ron Jeffries - Extreme Programming Adventures in C#. Да, примерите са на C#, но са така направени, че начинаещ ще ги разбере. Точно в тази книга дядо Рон описва как се учи на .НЕТ и с неговото другарче (Chet) пишат редактор за XML като практика. Вътре има пример с примитивно езиче за описване на тест сценарии, което парсват елементарно с регекси. Получават аксептънс тестове с примерен текст, позиция на курсора, изпълняване на команди и т.н. Това с минимум церемонии, нула външни инструменти и почти без добавена сложност. (Един от аргументите ми против Cucumber/Fit/Fitnesse е, че вкарват един тон глупости, когато човек просто иска да напише един-два теста). Отново, книгата е много забавна и Рон Джефрис е страхотен автор. Ако някой не го е чувал като име -- той е един от бащиците на Extreme Programming.

 

Примерно, сега ми се налага да бачкам с някакво конзолно приложение и
се чудя как да го тествам ?
Мога да напиша тестове които го стартират, подават му различни
аргументи и да гледам после резултата, примерно да пренасоча STDOUT и
STDERR и да ги прегледам, дали
са очакваните. Или пък мога да видя какви точно методи се викат, като
се извика bin-a и да тествам тях, но тези тестове не ми казват, че
всъщност реално bin-a работи както се очаква.
Тогава какви тестове трябват за да потвърдят, че и bin-a работи правилно ?

Ако не си правил пренасочването на stdout/stdin/stderr, пробвай го задължително, за да го изпиташ сам. Аз съм го правил и много ми хареса. После, на втората подобна задача, осъзнах, че е излишно усилие. Какво правя тези дни:

1) Не държа "истински" код в изпълнимия файл. Всичко е във външни класове.

2) Тествам обстойно тези класове. Там където трябва да работят със stdin/stdout/stderr подавам някакъв stream или каквото там му викат в Руби.

3) Main методът или скрипта, който се вика от клиента просто създава 1-2 от гореспоменатите класове и им подава argv/stdin/stdout/stderr. Обикновено той е 2-3 реда и спокойно мога да не го тествам.

Нека резюмирам. Мисля, че ни трябват по-малко *готови* инструменти и повече практика и мислене. Не бива да се притесняваме от това да си сглобим нещо наше, което да е точно насочено към конкретния проблем и също така е максимално просто.

Поздрави и успешно тестване,

Христо

P.S. В точка 3 по-горе мога да предложа и друг път за експериментиране. Тестване на клас с Main метод или драйвър скрипт като го викаме със специален параметър, който контролира кой "работен" клас ще се създаде. Проверка чрез създаване на фалшив обект за това дали входните параметри са предадени правилно. Не казвам, че това е правилна или грешна техника. Добре е да се изпрактикува и да си я имаме в кутията с инструментите.