Пускам това донякъде от любопитство, донякъде от желание да насочим клуба в посока смислени теми.

Интересува ме колко от вас ползват test-driven development в ежедневната си работа или поне се опитват да го учат.

Използвам TDD:
Всеки ден/за всяко нещо
Когато ме кара шефа или имам другарче, което ръчка за същото
Бих искал, но се притеснявам, че ще съм по-бавен в ежедневните задачи
Бих искал, но шефът не дава, защото мисли, че ще съм по-бавен
Интересно ми се, но не съм имал време да се науча
Това е пълна простотия и не искам да се занимавам с нея

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

Програмисването ми харесва понеже е неформален занаят (поне засега, поне за мене). Сетването на SciTEDirectory.properties да компилира отделен файл с дефине MAIN, а пък такъв с разширение .main.foo да билдне директорията и да рънне цялата простотия как е като термини.

SciTE е хубаво нещо, но напоследък ползвам Vim. И какво общо има това с темата?

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

Да, ползвах го за един проект. Получи се много добре. Написахме собствени модули и освен автоматизираните тестове добавихме и профилиране за да мерим времето което отнемат различните функции.

Най-после нещо смислено!

Преди 3-4 години трябваше да се пренапише едни стар ВБ компонент на .Нет за по-малко от две седмици. Тогава май за пръв път ми се наложи да пиша юнит тестове, без да е задължително тест-дривън.
Истински се зарибих по ТДД преди година и половина обаче. Пишехме три взаимно-свързани приложения (медицински осигуровки, ако някой го интересува) и бяхме решили да има юнит тест за всеки процес.
След като го предадохме проекта за 4 месеца вместо 6, даже шефа беше убеден. Оттогава е стандарт в нашия отдел.

TДД един подход само. Много фирми в София вече използват автоматизирани тестове. Използвате ли нещо повече? Някакви други хитринки за подобряване качеството на кода?

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

----------------------------------------
Здрав дух, в здрава бутилка!

От другите хитринки най-вече пеъринг на по-старшите с по-неопитни, същото но програмист с тестер, ежедневни ревюта. От ревютата като че ли ползата е най-малка.

Зависи за какви промени говорим. По принцип юнит тест се променя само ако има промяна в изискванията. Дори и тогава е доста по-лесно да се прецени кои тестове трябва да се променят и какви да се добавят и чак тогава да се пише код. Веднага се вижда кои точно парчета да се пипнат, че да светнат пак всички юнит тестове в зелено. Това важи най-вече при рефакторинг - спестяват се много главоболия при тестване на различните сценарии.

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

Разбира се, трябва дисциплина, за да се следва. Колегите в началото се оплакваха, че толково много неща имало да се мисли, сега и юнит тестове. В рамките на две-три седмици се убедиха, че като се премислят добре юнит тестовете, другото само си идва на мястото.

Обаче аз съм фанатик

размяната на кодерите по проектите, като е желателно да не са завършили проектите си. Доста помага за следващите проекти - качество, коментари, code style, спазването на конвенциите ...

Имам алергия към формалните ритуали. (Не, че има общо с темата :)
Идеята беше, че моеш да нариташ зрелищно неверника с примери как TDD препича филийки в тостера и ги маже с лютеница, като едновременно вари яйчицата, точно да са рохки и само ръсиш пипер и муаш :)

На мен това ми изглежда съвсем неформално. Значително по-формален подход е синтезиране на програмата (конструктивно) и т.н.

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

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

Изискванията са далеч не толкова стабилно нещо. В просец на писане изникват нови неща, оказва се по някога, че трябва архитектурата да се посмени, правят се оптимизации. Изобщо планирането тръгва от use case, а не от нещо техническо на което можеш да напишеш unit test. Промяна не е само това което клиента официално изисква след като види резултата.

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

----------------------------------------
Здрав дух, в здрава бутилка!

Ако не искаш да завършиш един проект и ако искаш екипа да се изпокара най-добрия начин е да разменяш хората по един таск. Всеки човек си има свой начин на мислене и свой стил (нямам предвид конвенция на писане), примерно аз никога не използвам цикли do-while. След смяна на човека се започва: това какво е, а това защо не е така, ама тоя интерфейс за чий си го изнесъл след като има само една имплементация ... я дай сега аз първо да си направя нещата да са като хората, да ти оправя бозите, а след това ще продължа нататък ... Да не говорим за загубата на време в разбиране на код който подлежи на промяна.

----------------------------------------
Здрав дух, в здрава бутилка!

Автоматични тестове, ръчни тестове, код ревюта, задължителна код конвенция и като капак по един качествен QA.

----------------------------------------
Здрав дух, в здрава бутилка!

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

Това разбира се е погрешна гледна точка. Ако нещата са кофти на ниво проектиране, се получава точно това което казваш - боза. Ако нещата са проектирани добре и достатъчно подробно и ясно, тогава остава проблема с колко ясно пишат кодерите. Идеята, че всеки кодер си има стил и това е важно, всъщност не е важна. От гледна точка на всеки тийм лидер (и нагоре) хората са ресурс и то заменим такъв. Да го кажем по друг начин, какво правиш ако един кодер си замине и ти трябва да предадеш неговите проекти на друг ?! Става стандартното - ооо колко лош програмист е напусналия и как трябва да се пренапише всичко. Резултатът - Загуба на време и в крайна сметка на пари!
Другото по темата - обикновено конвенции, стил, коментари и т.н. са нещо което никой кодер не спазва. Това е начина да ги накараш да разберат колко е важно всъщност. Дори да се стигне до полускандал, изводите са очевидни - пишете така, че другия да ви разбере писанията! Понеже тийм лидера, ПМ или който да е отговорния фактор не може да се съобразява с всеки кодерски стил, то кодерите ще се съобразява с това което е прието за стандарт в фирмата.

Юнит тестовете са най-полезни точно когато архитектурата не е вече актуална и трябва да се смени. Как според теб може да се докаже, че рефакторинга не е счупил нещо, докато сме се опитвали да решим даден проблем? По предишния проект пълен регрешън се правеше за 3 дни от двама тестери. Няма начин да чакаме толкова дълго. За сметка на това добре проектираните юнит тестове ти дават отговор в рамките на минута-минута и половина.

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

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

<quote>
Автоматични тестове, ръчни тестове, код ревюта, задължителна код конвенция и като капак по един качествен QA.
</quote>

Да, и 100 мармота също, за всеки случай. И едно пони.

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

Един QA по-малко, вноска за Кайен. Двама QA по-малко - Кайен и наем на вилата на Пенчо Кубадински в Бояна.

Сторнатите процедури по стандарт трябва да са тъпи и да не съдържат почти никаква логика.
Можем да поспорим тук

Съдържаниет е скрито
Влезте за да го видите

Без QA е доста трудно. Това програмист да си тества бозите, пиши го пропаднал проекта.

Не отричам. Без нещо_си е по-трудно обикновено да се свърши нещо отколкото с нещо_си. Ето примерно, без щатна масажистка е доста по-трудно да се свърши проекта отколкото с щатна таква, няма никакакъв спор за това нещо.

Особено ако си свикнал.

Може би се изразих грешно. Думата 'трудно' я използвах погрешно.
Проблема е дали искаш да превърнеш производството на софтуер в манифактура и по възможност да избегнеш прословутите простотии от типа - 'програмирането е изкуство'.

Да се върнем на Кайена, че тука взе да става сложно.

Много зависи какво правиш. Ако е продукт, който трябва да е съвместим с максимален брой видове бази данни, забрази за сторед проседурес.

Грешиш. Точно тогава разчиташ максимално на SP

На ръка ли ги пишеш тия Сторнати процедури, не те ли мързи? Слънце пече, на море ходят хората (в Брисбейн, да не си помислиш нещо). SQLMetal.exe са направили хората, там... програмирали са 10 години 1000 човека, тествали са, що се мъчиш.. линк, млинк, ЕФ, алабала.

Въпрос подходящ за интервю: В последния си проект, как съхранявахте сторнатите си процедури в соурс контрол?

Въпрос подходящ за този тред на вече интелигентния клубс.дир.бг: как пишеш юнит тестове на сторнати процедури?

Греша друг път

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

Юнит тестовете от QA няма да те отърват, но ще ги минимизират. Както и броя на бъговете, че да имаш време да си го прекарваш по плажовете на Бризбейн.

Така де, минимизиране на QA, максимизиране на Кайените преди да падне метеорита в 2010-а. Няма много време. Юнит тестовете са пътя към пълноценния живот в тези две години, които ни остават. И Калгон.

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

Съдържаниет е скрито
Влезте за да го видите

Да ти задам въпроса по друг начин. Нима си толкова наивен, че смяташ ANSI 92 SQL (например) за нещо което всички спазват ?! Нима е по лесно да коригираш SQL SELECT изрази в кода ? Нима не е по лесно да напишеш оптимална SP според SQL сървъра който ползваш ?
Какво ще кажеш за момента :
тънък клиент - app.server - db ?
Нима SP не е най ефективния начин за ползване на DB ?
Дaли не е по лесно, сменяйки DB сървъра да се разпишат SP или да се правят кръпки в сорса ?!

"И Калгон."

Ахаха, тва ме трепе - тая варовита софийска вода. Искрено се забавлявам на женките дето мрънкат за калгон у фантастикото. Забавното е, че вместо шамар или поне намек (като е по-интелигентна чумата), сериозни хора (примерно с кайен) почват - ама бубе, ала бала. Бе опак край

Съдържаниет е скрито
Влезте за да го видите

Ползвам TDD винаги. Проектът, по който работя, има няколко хиляди юнит теста. Открих, че печеля много от TDD - кодът ми e по-добър и има по-малко бъгове. Видях доста коментари, че TDD обезсмисля QA-ите. Ами това не е вярно. Освен unit tests има и други видове тестове, които могат да се правят от QA хора и да допринасят за качеството на един продукт.

(Бях "Теляка" едно време)

Редактирано от Kopчeв на 12.11.08 01:14.

Аз няма да споря с теб. И ти си прав, в смисъл по който и начин да тръгнеш, можеш да постигнеш добър резултат, това не е математика, за да има само един верен отговор. Дори понякога пералнята може да работи повече от 3 години ако не и слагаш Калгон (въпрос с повишена трудност: ако слагаш Калгон в всяко пране, парите които ще дадеш за 3 години повече ли са от чисто нова пералня последен модел, нещо като Зорт-а на пералните)

Все пак тенденциите напоследък е да се генерира този лейър дето ти му викаш сторнати процедури и вече SQL-а да се генерира от това дето му викат провайдър. Сега, на теория, ти може и по-добре да си го напишеш на ръка ама... ти може да си добър, аз лично не мога. Щом си толкова добър - ето ти идея за продукт - провайдър за Оракъл за EF / Linq на новия .НЕТ 3.5. Може да станеш по-богат от Питър Нортън и Линус Торвалдс едновременно.

Също така не отговри на въпросчетата как си тестваш с юнити T-SQL-а и как си пазиш сторнатите процедури в соурс контрол да им следиш промените.

:) тестването на SP става чрез известното от време оно полуавтоматично средство - QA .
В сорс контрол се пази script-a на цялото DB.

Принципно, съм силен привърженик на идеята : колкото по малко SQL изрази в сорса, толкоз по добре. Не само заради потенциалната смяна на DB-то (тук се включва и ползването на по нови версии на основното за ползване ДБ), но и заради ясното разграничение/разслояване на приложението. Да, съгласен съм че дори викането на сторнати процедури не е универсално средство, но все корекциите са по малко отколкото хиляди sql изрази в сорса.
Има и други екстри в позлването на SP.... но както казах, според зависи от проекта е.
Колкото за идеята да пиша провайдър :)) мерси, но за момента нямам особено много свободно време

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

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

Дай на някой нещо незавършено и той има свободата да го преправя и да се мота - дай му завършен продукт да поддържа или доразвива и няма да променя стила на предшественика си.
Хората са заменими, но си има време когато е по-лесно и време когато е по-трудно да смениш някой.

----------------------------------------
Здрав дух, в здрава бутилка!

Код ревюто е максималкото време което си струва да се ползва за уеднаквяване на кода. При него има и друго полезно - могат да се открият грешки или възможности кода да избие нейде.

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

----------------------------------------
Здрав дух, в здрава бутилка!

QA има друг поглед върху продукта - не толкова технически, колкото ориентиран към клиента. Това ти дава един друг вид тестване.
Да не говорим колко са задачите по осигуряване на качеството които един делелъпер ще каже, че не му се занимава с тях и ще ги направи през пръсти.
За малки програмки можеш да минеш и без QA, но за голям продукт - забрави.

----------------------------------------
Здрав дух, в здрава бутилка!

И последно кое е по-упорито - петното или кашлицата

Съдържаниет е скрито
Влезте за да го видите

Бира, кола, кафета, пици, дългокраки секретарки и прочее ... но това не са от важните фактори

Съдържаниет е скрито
Влезте за да го видите

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

Правиш една фукнционалност, след това и правиш тест, после започваш следващата ... това за мен е правилния подход, но това не е ТДД.

----------------------------------------
Здрав дух, в здрава бутилка!

Чакай сега, ами какво правят модерните напоследък на само в квартал Кастро в Сан Франциско така наречени юзър експириънс пичове? Те не следят ли от страната на клиента какво ще стане?

Девелопера автоматизира това е ясно и пише юнит тестове, добре, аз не мога да разбера QA-те дето не могат да програмират и автоматизират какво правят точно?

Все пак не забравяй - заплата на едно QA - вноска за Кайен. Примерно ако сложиш на един кантар, от тия с везните дето Темида ги носи - един Кайен на едната везна и едно QA на другата, кое ще е натежи повече? Според мене Кайено тежи доста повече от едно QA.

Редактирано от Mr T на 12.11.08 16:25.

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

Но юнит тестовете са много добри при регрешън. Примерно идва ти бъг от QA-a (тука си представи, че ако го нямаше този QA нямаше да го има този бъг но можеше да има Кайен) и преди да го фикснеш пишеш тест който да фейлва, след фикса теста трябва да мине и така остава регрешън тест.

Ако се прави постоянно (да кажем тийм от 4-5 девс фиксват 2-3 бъга на ден всеки), може само за 3-4 месеца да имаш страхотен пакет (не това което си мислиш, друго) от 2000 регрешън теста и да махнеш 1-2 QA-та и с парите да си купиш... сещаш се.

<quote>
:) тестването на SP става чрез известното от време оно полуавтоматично средство - QA .
</quote>

И как работи това? "Пешооо, смениш сторната процедура дето вади броя на бикините по доставчик, виж там дали не се е насрало нещо като се върнеш от обяд"

<quote>
В сорс контрол се пази script-a на цялото DB.
</quote>

И как работи това? При всяка една промяна на нещо в ДБ, експортваш скрипта, слагаш го във файл и той стои в соурс контрола? Всеки от тийма прави това? Или как? Нещо слуша за промени и автоматично при промяна експортва скрипта? Всичкия код на всичките процедури в един файл ли е? Ами ако са 1000? Ами ако трябва да провиш порт от MSSQL към Оракъл какво правиш? Целия T-SQL го преписваш на PL/SQL? На ръка?

пич
:) ако базата се променя толкова често, че едва ли не излиза извън контрол, то проблема със сигурност не е в базата. Смени си шефовете, ПМ, ТЛ или там който е безотговорния фактор!

Edit: Пак да кажа! Липсата на идея кво праиш, никога не прощава в дългосрочен план. Ако аз требе а си сменям структурата на базата едва ли не всеки ден, ще се самоубия ритуално! Какво по дяволите правиш, ако поне една шибана ДБ не си дефинирал така, че да не оцелее повече от ден като структура !

Редактирано от mlee на 12.11.08 22:45.

Ей тук има обстоен флейм за и против сп-тата, струва си да се прочете. Обосновани мнения.

Съдържаниет е скрито
Влезте за да го видите

В отговор на:

---

можеше да стане въпрос за BDD, и дали някой реално го е пробвал

---

Съдържаниет е скрито
Влезте за да го видите

Oтчасти е така, отчасти - не. Не забравяй, че има и други видове тестове освен юнит. Например интеграционни тестове. Не знам ти дали би писал тестове на Слениум, WatiN/WatiR и т.н. Всеки тест, който има вземане даване с базата данни, "бара" файловата система, отваря прозорци, не е юнит тест. Обикновено на такива тестове им се вика integration tests дори и да ги пускаш с TestDriven.Net и да ползваш NUnit/MS Test/xUnit (кредора трябва да умре по много гаден начин - имам си кирилица в уиндолса мамка му, не ми трябва насран джаваскрипт плъгин). Като цяло искам да кажа, че TDD не обезсмисля QA. Има поле за изява за всеки

Съдържаниет е скрито
Влезте за да го видите

Като така да се каже познавач, бих заложил на петното :)

TDD is not the ultimate paradigm. Ако напишеш първо теста, може би знаеш какво всъщност искаш да направиш

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

Ами мъчим го тука, с shoulda. Има "макроси", с които описваш поведението на м-тата и ц-тата. Нещо обаче не мога да се убедя още в употребата му... По-скоро дава файда за хващане на случайни грешки при рънването на кода, отколкото да е реален спек.

Може би цаката е един да пише спек тестовете, друг да ги имплементира, знам ли?

— У вас, на Земята, как определяте кой пред кого колко пъти да клекне?
— Така, на око…
— Диваци!

ТДД значи тестовете първо и за мен това не е правилно.
Иначе самото наличие на тестове влиза във всеки процес. А за ползата им е ясно.

----------------------------------------
Здрав дух, в здрава бутилка!

Темата не е за това дали да се пишат тестове, а дали ТДД е добър като процес. Най-важното в този спор е точно кога се пишат тестовете.

----------------------------------------
Здрав дух, в здрава бутилка!

Като чета, и придобивам чувството, че някой ти е казал, че всички тестове се разписват предварително и тогава се сяда да се пише кода. Това не е така.

Съдържаниет е скрито
Влезте за да го видите

Принципите на тестера:

Тестерите не ходят на работа, за да завързват приятелства.

Вярваме в Бог, всичко останало го тестваме.

Тестерите не чупят софтуера - той вече е счупен, когато пристига при тях.

Тестерите винаги отиват в рая - те вече са получили своята част от ада тук.

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

Това са бъговете - ако тези не ти харесват имам и други.

Ако не е счупено, значи не си опитвал упорито.

Добрият тестер има сърце на програмист… в буркан на бюрото си.

Тестерите не обичат да чупят нещата, те харесват разрушаването на илюзията, че тези неща работят.

Винаги има още един бъг.

Наша работа е да ви кажем, че отрочето ви е грозно.

“Да тестваш или не - туй не е въпрос!”

Съдържаниет е скрито
Влезте за да го видите

Защо мислиш, че не е правилно? Дай някакви доводи, за да стане дискусия. Аз ще дам моите доводи:

1. Тест първо ме кара да мисля малко повече, преди да напиша поредната глупост.
2. За да мине теста, пиша минималното количество код. Тоест поддържам по-малко код, което не е малко :)
3. Често докато пиша теста се сещам за следващия тест - друг сценарий, който трябва да покрия - гранични случаи например.

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

-------------------
Ex "Теляка"

Това което аз съм виждал от този просец е именно, че тестовете се пишат преди кода или поне основните тестове, затова е и тест-дривън. Иначе, ако просто говорим да има пълен набор тестове, това не изисква специален процес.

----------------------------------------
Здрав дух, в здрава бутилка!

1. Тест първо ме кара да мисля малко повече, преди да напиша поредната глупост.
Архитектурата и дизайна са това което те кара да мислиш предварително и предпазва от правене на глупости.

2. За да мине теста, пиша минималното количество код. Тоест поддържам по-малко код, което не е малко :)
Това не го разбрах - в кода или в кода на теста? Повечето код и допълнителните екстри надали ще ти свалят теста - не и ако са написани качествено.

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


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

----------------------------------------
Здрав дух, в здрава бутилка!

Само да те питам, ти доволен ли си от качеството на тестовете като ги пишете след като сте събрали димящата купчина код? Щото хората дето пишат тестовете предварително изглеждат доста happy, ама може само да се правят.

Съдържаниет е скрито
Влезте за да го видите

В отговор на:

---

Архитектурата и дизайна са това което те кара да мислиш предварително и предпазва от правене на глупости.

---

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

<<EOQ
1. Тест първо ме кара да мисля малко повече, преди да напиша поредната глупост.
2. За да мине теста, пиша минималното количество код. Тоест поддържам по-малко код, което не е малко :)
3. Често докато пиша теста се сещам за следващия тест - друг сценарий, който трябва да покрия - гранични случаи например.
EOQ

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

Съдържаниет е скрито
Влезте за да го видите

Когато са написани тестове - да. За съжаление не винаги има, но напоследък ставаме по-дисциплинирани.

----------------------------------------
Здрав дух, в здрава бутилка!

"Писането на тестове след кода е ужасна мъка, защото обикновено кодът е писан без грам замисъл за тестваемост" - кода си има цел, а ти тестваш целта, тя е винаги тестваема

Повечето усмивки се базират на съвсем други неща, освен това е доста трудно да го докажеш, защото става дума за субективни фактори и възприятия.

Да си напишеш кода добре не зависи от процес, а от човек.

----------------------------------------
Здрав дух, в здрава бутилка!

Тук вече навлизаме във философски размисли. Обаче като се тегли чертата, ползите от ТДД са повече, отколкото без ТДД.

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

Ние опитахме по един проект БДД. С две думи - не е лесно. Най-трудното беше да се накарат клиентите да седнат на масата (образно казано) и да обяснят подробно какво аджеба се иска. Като че ли това е и най-трудната част от всеки проект по принцип - да се определят критериите за "приемливост". Следващата трудност беше тези критерии да се вкарат в "изпълними" тестове. Опитахме с Фитнессе, но нещо не проработи както трябва. Автоматизираните тестове също не дадоха кой знае какъв резултат. В крайна сметка процеса се сведе до обичайните ръчни тестове + юнит тестове.

Та на пръв поглед идеята на БДД е доста интересна - да се изкарат юнит тестовете на по-високо ниво. Но на практика за нас се оказа неприложима.

Изкарвам обратния резултат като тегля чертата

Съдържаниет е скрито
Влезте за да го видите

И после, след като са надлежно прегледани, поправени и прошнорувани, да се хвърлят на боклука, щото нещо, което на хартия е изглеждало супер, на практика се оказва не чак толкова добра идея (меко казано).

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

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

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

----------------------------------------
Здрав дух, в здрава бутилка!

Не знам точно каква е идеята на ТДД, но аз съм стигнал до няколко извода и гледам, че тук ги коментирате и тях.

1. По време на дизайна (на архитектурата) мисли и за тестването. Код (архитектура) която не е мислена за тестване много трудно се тества.

Един стар проект имаме без да е замислен за юнит тестове. Ми то, за да му тестваш персистансето ти трябва апликейшън сървър.

Сега всичко ново, което правим го мислим и как да се тества. Т.е. архитектурата да позволява тестване на всички нива отделно като юнит тестове и като интеграционни тестове като няма такива зависимости.


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


3. Тестване на всички нива, на които можеш да тестваш.



Преди 2-3 седмици бях пуснал една тема за тестване на сървлети. Те такова тестване нямахме още и аз не бях правил, та реших да направя сега. Споделям опит и какво направихме по темата.


Значи до момента имаме пълно разделение на логиката от презентацията. ПОЖО класове + персистансе. За тях имаме юнит тестове тестващи логиката, доколкото я има (щото няма много логика) и персистансето (всъщност това е по-важно за тестване).

После другото ниво са сървлетите, които изпълняват няколко задачи: секюрити; диспетчинг; инициализиране на обекти като се четат параметри от рекюеста; викане на някакви методи на тези обекти било за запис, търсене или каквото друго трябва; пъхане на разни неща из сесията, които ще трябват при следваща заявка от страна на браузъра и неща от сорта.

Презентационното ниво е JSP. Сървлета прави каквото прави и пъха разни неща в контекста на рекюеста и после вика някакво JSP, което показва нещата на екрана. Стандартна (даже малко остаряла) архитектура. :)



Та идеята ми беше как да се хвани логиката в сървлетите. И ви питах за опит. Та мислих, мислих и какво измислих.

Значи редиректа към JSP минава през едно място (един метод). Сървлетите си викат едно методче с параметър името на JSP страницата и метода вика JSP-то. Перфектно място да се "хванат" нещата.

Та този метод в тестов режим вместо да вика JSP-то сериализира рекюеста в ХМЛ и го праща към браузъра. Това включва: всички параметри изпратени от браузъра; хедърите на рекюеста; атрибутите на рекюест контекста; атрибутите на сесията; и още каквото може да се докопа.

Та всичко това се праща от сървъра в ХМЛ формат към клиента.

От страната на клиента ХМЛ се десериализира обратно в съответните обекти и с JUnit правя съответните assert-и да видя състоянието на обектите и дали изобщо го има.

Ползвам XStream за ХМЛ сериализация и HttpClient от Апаче за клиент. Това последното поддържа кукита и съответно автоматично си поддържа сесията.

Понаписах около 100 реда код да направя нещата по-лесни за викане. HttpClient има супер флексибъл архитектура и може да прави всичко, ама аз искам с един метод да си сетна параметрите, а не да инициализирам 20 неща за да сетна един параметър. Та си понаписах малко код около XStream и HttpClient.


Недостатъците са, че е хоме майд солюшън. Обаче мен ме кефи в няколко аспекта:

1. Кодът се изпълнява както в продакшън без никакви допълнения.
2. Тестовият код симулира браузър.
3. Получавам обектите в сесията и рекюеста. Мога да ги контролирам по бройка и размер. Мога да следя във всеки един момент какви боклуци има в сесията и да ги разкарвам когато не ми трябват. Т.е. мога да гледам ако съм вкарал нещо повече в сесията или в рекюеста. Така се намалява използваната памет.
4. Това симулира интеграционен тест на всички нива без последното (презентационното).
5. Много ясно, точно и конкретно се тества логиката, която я има в сървлетите. Значи сървлета получава такива и такива параметри. На базата на тях очаквам в сесията да имам този и този обект, а в рекюест контекста този и онзи обект. Просто перфектно - все едно тестваш публични методи на класове, а те колко прайвът методи викат си е тяхна работа.

Това се доближава до Кактус на Апаче за тестване на J2EE код, ама Кактуса ми се стори прекалено сложен и реших да ходя с хоме мейд солюшън. :)

Това не заменя тестването със Селениум или нещо друго в браузъра. Защото може да има грешки в JSP (JS) кода, които няма как да се хванат тук.


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

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

Идеята с XML сериализацията ми се струва проста и красива. Може да я използвам някой ден

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

Малко отплеснахме темата в посока уеб тестване, ама какво пък. Пробвали ли сте Selenium или някое от хилядата решения за скриптиране на IE през COM интерфейса: Watir, WatiN, и т.н.?

Съдържаниет е скрито
Влезте за да го видите

Точно WatiN не, обаче доста си поиграхме с вградения Web Test на Студиото. Най-големия ни проблем беше с тестване на AJAX простотиите. Аз понеже хич ме няма там, си се закопах обратно в бек-енда по онова време. Сега обаче ми излезе през носа...

За веб тестването си мисля, че да тестваш view-то като код (разбирай html) е overkill, освен ако не правиш супер продукт. И тогава не е много сигурно, че има файда.

Одобрявам и заставам отзад на това, дето му викат functional testing -

Съдържаниет е скрито
Влезте за да го видите

Всъщност първата ми идея беше с онова Кануу, което уж може да работи на някакъв подобен принцип на браузъра, но се отказах.

За XHTML+XPath не съм мислил, защото презентацията ни ползва едни JS библиотеки и понякога връща само JS без HTML. Отделно си зависим от дизайнерите, които трябва да пишат XHTML и ако объркат нещо ще почнат да фейлват тестовете. Та по-скоро исках да изключа презентацията, отколкото да я включа.

Така стана суперско. Клиентът (т.е. тестът) си десериализира XML-а обратно в обекти и ги чеква по дадени правила. И по този начин се тества само логиката на сървлетите без презентацията. Демек контролера от MVC-то. Стана супер хитро. Отделно можеш да тестваш съдържанието на сесията и разни други неща, които не е длъжно да се презентират, но могат да имат влияние в/у по-нататъшни действия.

Много съм доволен - просто и елегантно решение. За Веба-Джава с MVC архитектура просто е перфектно.