Какво е предимството на използването на Fitness спрямо автоматизираните интеграционни тестове?

Тестовите случаи в Agile среди се предлагат главно в четири основни типа:

1) Автоматизирани единични тестове (напр. използване на J-единица);

2) Автоматизирани тестове за проверка на характеристиките (напр. използване на Fitnesse);

3) Автоматизирани функционални/регресионни тестове (напр. използване на Selenium или QuickTestPro);

4) Ръчно тестване.

За типове 1-3, разбира се, има определени автоматизирани тестови случаи. За тип 4 тестовите случаи са склонни да бъдат логически (или на високо ниво) тестови случаи, което изисква по-високо ниво на умения и познания в областта на тестерите. Също така има тенденция да се извършва значително количество базирано на опит тестване, като проучвателно тестване, тестване на таксономия на дефекти и т.н.

Вижте блога на RBCS тук:

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

Лично аз открих, че FIT създава повече проблеми, отколкото си струва. Мисля, че може да е наистина завладяващ инструмент, ако създателите се заемат сериозно и направят някои инструменти, за да го настроят и конфигурират.

Но най-важното е да го използвате само ако сте сигурни, че ще имате много неща от типа на бизнес правила, за да проверите, в които BA или дори Клиенти могат да участват директно. Това не е за твърдение, че орбитална константа се изчислява правилно.

Fitness трябва да улесни бизнес анализаторите да притежават и изпълняват тестове. Разработчиците създават приспособления; бизнес анализаторите подават данни и потвърждават, че тестовете преминават.

Според моя опит бизнес анализаторите нямат нито опит, нито интерес да направят подобно нещо.

Фитнес тестовете са по-скоро интеграционни тестове. Те могат да включват няколко компонента. Модулните тестове трябва да се извършват от разработчиците на отделни компоненти. Оттук и името "единица".

Предпочитам unit tests.

Въпросът предполага фалшива дихотомия; FitNesse е автоматизирано решение за тестване на интеграция. Просто тестовете са (предназначени да бъдат) създадени като маркиране в уики страници.

В момента го използвам като мое решение за тестване на интеграция; Изпълнявам всички интеграционни тестове, като използвам командния ред. Тестовете могат също да се изпълняват чрез JUnit или REST API (което ще изисква стартиране на сървъра FitNesse).

Както Роб споменава в своя отговор, не е (много) лесно да се настрои и конфигурира, но и аз не го намерих труден. И аз оспорвам твърдението на Роб, че „Това не е за твърдение, че една орбитална константа се изчислява правилно.“; всъщност той е напълно използваем точно за това.

Попаднах на този въпрос, защото търсех оценки от хора, използващи или хора, които са използвали Fit или FitNesse за единично тестване. Причината, поради която тази идея ми хрумна, е, че като разработчик намирам за много по-лесно да разбера набор от тестове под формата на уики страница на FitNesse, отколкото файл с код.

По-долу е даден пример за тестова страница от един от моите проекти. Тези тестове са интеграционни тестове, но не мога да се сетя за причина, поради която това да не работи добре и за модулни тестове. Няма нищо особено в кода за тестовете, което да попречи на тестването на единици.