TDD употреба
77 отговора
0 прегледа
TDD употреба
Пускам това донякъде от любопитство, донякъде от желание да насочим клуба в посока смислени теми.
Интересува ме колко от вас ползват test-driven development в ежедневната си работа или поне се опитват да го учат.
Тези, които са зарибени, бихте ли споделили как се зарибихте и от кои ресурси се учихте.
Допълнително ми се върти из главата да направя група за взаимно обучение по материята и се чудя как го приемат другите и как е най-добрият начин да се организира цялото начинание.
Интересува ме колко от вас ползват test-driven development в ежедневната си работа или поне се опитват да го учат.
Тези, които са зарибени, бихте ли споделили как се зарибихте и от кои ресурси се учихте.
Допълнително ми се върти из главата да направя група за взаимно обучение по материята и се чудя как го приемат другите и как е най-добрият начин да се организира цялото начинание.
Използвам TDD:
Гласували: 25
Влезте, за да гласувате.
Re: TDD употреба
Програмисването ми харесва понеже е неформален занаят (поне засега, поне за мене). Сетването на SciTEDirectory.properties да компилира отделен файл с дефине MAIN, а пък такъв с разширение .main.foo да билдне директорията и да рънне цялата простотия как е като термини.
в отговор на Eвлaмпи Пoпдимитpoв
#3
Re: TDD употреба
SciTE е хубаво нещо, но напоследък ползвам Vim. И какво общо има това с темата? 
Re: TDD употреба
Най-после нещо смислено!
Преди 3-4 години трябваше да се пренапише едни стар ВБ компонент на .Нет за по-малко от две седмици. Тогава май за пръв път ми се наложи да пиша юнит тестове, без да е задължително тест-дривън.
Истински се зарибих по ТДД преди година и половина обаче. Пишехме три взаимно-свързани приложения (медицински осигуровки, ако някой го интересува) и бяхме решили да има юнит тест за всеки процес.
След като го предадохме проекта за 4 месеца вместо 6, даже шефа беше убеден. Оттогава е стандарт в нашия отдел.
Преди 3-4 години трябваше да се пренапише едни стар ВБ компонент на .Нет за по-малко от две седмици. Тогава май за пръв път ми се наложи да пиша юнит тестове, без да е задължително тест-дривън.
Истински се зарибих по ТДД преди година и половина обаче. Пишехме три взаимно-свързани приложения (медицински осигуровки, ако някой го интересува) и бяхме решили да има юнит тест за всеки процес.
След като го предадохме проекта за 4 месеца вместо 6, даже шефа беше убеден. Оттогава е стандарт в нашия отдел.
в отговор на lndependent
#6
Re: TDD употреба
TДД един подход само. Много фирми в София вече използват автоматизирани тестове. Използвате ли нещо повече? Някакви други хитринки за подобряване качеството на кода?
Re: TDD употреба
На мен този процес ми се струва малко краен. Да, трябва да имаш някаква идея за тестовете преди да си почнал всичко, добре е да има тестове направени по спецификацията, а не само по това което е вече готово. Но все пак да не се престараваме, защото всяка промяна започва да излиза доста по-скъпо.
----------------------------------------
Здрав дух, в здрава бутилка!
----------------------------------------
Здрав дух, в здрава бутилка!
в отговор на Лaнc Линk - тaйният areнт
#9
Re: TDD употреба
Зависи за какви промени говорим. По принцип юнит тест се променя само ако има промяна в изискванията. Дори и тогава е доста по-лесно да се прецени кои тестове трябва да се променят и какви да се добавят и чак тогава да се пише код. Веднага се вижда кои точно парчета да се пипнат, че да светнат пак всички юнит тестове в зелено. Това важи най-вече при рефакторинг - спестяват се много главоболия при тестване на различните сценарии.
Точно същия спор го имахме с шефа. В един случай ни излезе по-евтино (и по-бързо) с ТДД, в няколко случая не се забеляза кой-знае каква печалба, но пък качеството на кода (и на приложението) беше забележимо по-добро.
Разбира се, трябва дисциплина, за да се следва. Колегите в началото се оплакваха, че толково много неща имало да се мисли, сега и юнит тестове. В рамките на две-три седмици се убедиха, че като се премислят добре юнит тестовете, другото само си идва на мястото.
Обаче аз съм фанатик
Точно същия спор го имахме с шефа. В един случай ни излезе по-евтино (и по-бързо) с ТДД, в няколко случая не се забеляза кой-знае каква печалба, но пък качеството на кода (и на приложението) беше забележимо по-добро.
Разбира се, трябва дисциплина, за да се следва. Колегите в началото се оплакваха, че толково много неща имало да се мисли, сега и юнит тестове. В рамките на две-три седмици се убедиха, че като се премислят добре юнит тестовете, другото само си идва на мястото.
Обаче аз съм фанатик
Re: TDD употреба
Имам алергия към формалните ритуали. (Не, че има общо с темата :)
Идеята беше, че моеш да нариташ зрелищно неверника с примери как TDD препича филийки в тостера и ги маже с лютеница, като едновременно вари яйчицата, точно да са рохки и само ръсиш пипер и муаш :)
Идеята беше, че моеш да нариташ зрелищно неверника с примери как TDD препича филийки в тостера и ги маже с лютеница, като едновременно вари яйчицата, точно да са рохки и само ръсиш пипер и муаш :)
в отговор на Eвлaмпи Пoпдимитpoв
#12
Re: TDD употреба
На мен това ми изглежда съвсем неформално. Значително по-формален подход е синтезиране на програмата (конструктивно) и т.н.
Този подход - TDD - има някакъв приложнически чар. При съвременното "програмиране", което е скалъпване на някакви библиотеки и получаване на продукт, ми се струва доста добър подход. Това е занаятчийска техника и в контекста на българското производство, струва ми се, по-начало нихилистичният народен работодател би имал полза да инвестира в някаква подготовка на персонала си в тази и подобни области, колкото и реалният development да не е приоритетен в нашите предприятия.
Този подход - TDD - има някакъв приложнически чар. При съвременното "програмиране", което е скалъпване на някакви библиотеки и получаване на продукт, ми се струва доста добър подход. Това е занаятчийска техника и в контекста на българското производство, струва ми се, по-начало нихилистичният народен работодател би имал полза да инвестира в някаква подготовка на персонала си в тази и подобни области, колкото и реалният development да не е приоритетен в нашите предприятия.
в отговор на lndependent
#13
Re: TDD употреба
Добро нещо в ТДД е факта, че на края наистина имаш тестове и не може да се случи след като продукта е готов девелъпара да каже "айде сега, виж го колко добре работи, за чий ми е да си губя времето с тестове", а шефа му "майната им на тестовете, от тях пари не се печелят - дай да правим новия проект".
Изискванията са далеч не толкова стабилно нещо. В просец на писане изникват нови неща, оказва се по някога, че трябва архитектурата да се посмени, правят се оптимизации. Изобщо планирането тръгва от use case, а не от нещо техническо на което можеш да напишеш unit test. Промяна не е само това което клиента официално изисква след като види резултата.
За мен правилната последователност е в началото да има само бегли описания на тестове - не толкова да се следи качеството, колкото да не ти се изплъзне крайната цел. След това реалните тестове трябва да се появяват при завършен компонент. Това спестява всички усилия по преправяне на тестове и допълнително улеснява самото им писане.
----------------------------------------
Здрав дух, в здрава бутилка!
Изискванията са далеч не толкова стабилно нещо. В просец на писане изникват нови неща, оказва се по някога, че трябва архитектурата да се посмени, правят се оптимизации. Изобщо планирането тръгва от use case, а не от нещо техническо на което можеш да напишеш unit test. Промяна не е само това което клиента официално изисква след като види резултата.
За мен правилната последователност е в началото да има само бегли описания на тестове - не толкова да се следи качеството, колкото да не ти се изплъзне крайната цел. След това реалните тестове трябва да се появяват при завършен компонент. Това спестява всички усилия по преправяне на тестове и допълнително улеснява самото им писане.
----------------------------------------
Здрав дух, в здрава бутилка!
Re: TDD употреба
Ако не искаш да завършиш един проект и ако искаш екипа да се изпокара най-добрия начин е да разменяш хората по един таск. Всеки човек си има свой начин на мислене и свой стил (нямам предвид конвенция на писане), примерно аз никога не използвам цикли do-while. След смяна на човека се започва: това какво е, а това защо не е така, ама тоя интерфейс за чий си го изнесъл след като има само една имплементация ... я дай сега аз първо да си направя нещата да са като хората, да ти оправя бозите, а след това ще продължа нататък ... Да не говорим за загубата на време в разбиране на код който подлежи на промяна.
----------------------------------------
Здрав дух, в здрава бутилка!
----------------------------------------
Здрав дух, в здрава бутилка!
в отговор на Лaнc Линk - тaйният areнт
#16
Re: TDD употреба
След смяна на човека се започва: това какво е, а това защо не е така, ама тоя интерфейс за чий си го изнесъл след като има само една имплементация ... я дай сега аз първо да си направя нещата да са като хората, да ти оправя бозите, а след това ще продължа нататък ... Да не говорим за загубата на време в разбиране на код който подлежи на промяна.
Това разбира се е погрешна гледна точка. Ако нещата са кофти на ниво проектиране, се получава точно това което казваш - боза. Ако нещата са проектирани добре и достатъчно подробно и ясно, тогава остава проблема с колко ясно пишат кодерите. Идеята, че всеки кодер си има стил и това е важно, всъщност не е важна. От гледна точка на всеки тийм лидер (и нагоре) хората са ресурс и то заменим такъв. Да го кажем по друг начин, какво правиш ако един кодер си замине и ти трябва да предадеш неговите проекти на друг ?! Става стандартното - ооо колко лош програмист е напусналия и как трябва да се пренапише всичко. Резултатът - Загуба на време и в крайна сметка на пари!
Другото по темата - обикновено конвенции, стил, коментари и т.н. са нещо което никой кодер не спазва. Това е начина да ги накараш да разберат колко е важно всъщност. Дори да се стигне до полускандал, изводите са очевидни - пишете така, че другия да ви разбере писанията! Понеже тийм лидера, ПМ или който да е отговорния фактор не може да се съобразява с всеки кодерски стил, то кодерите ще се съобразява с това което е прието за стандарт в фирмата.
Това разбира се е погрешна гледна точка. Ако нещата са кофти на ниво проектиране, се получава точно това което казваш - боза. Ако нещата са проектирани добре и достатъчно подробно и ясно, тогава остава проблема с колко ясно пишат кодерите. Идеята, че всеки кодер си има стил и това е важно, всъщност не е важна. От гледна точка на всеки тийм лидер (и нагоре) хората са ресурс и то заменим такъв. Да го кажем по друг начин, какво правиш ако един кодер си замине и ти трябва да предадеш неговите проекти на друг ?! Става стандартното - ооо колко лош програмист е напусналия и как трябва да се пренапише всичко. Резултатът - Загуба на време и в крайна сметка на пари!
Другото по темата - обикновено конвенции, стил, коментари и т.н. са нещо което никой кодер не спазва. Това е начина да ги накараш да разберат колко е важно всъщност. Дори да се стигне до полускандал, изводите са очевидни - пишете така, че другия да ви разбере писанията! Понеже тийм лидера, ПМ или който да е отговорния фактор не може да се съобразява с всеки кодерски стил, то кодерите ще се съобразява с това което е прието за стандарт в фирмата.
в отговор на Лaнc Линk - тaйният areнт
#17
Re: TDD употреба
[линк]
god is real...
if not defined as integer
god is real...
if not defined as integer
в отговор на Лaнc Линk - тaйният areнт
#18
Re: TDD употреба
Юнит тестовете са най-полезни точно когато архитектурата не е вече актуална и трябва да се смени. Как според теб може да се докаже, че рефакторинга не е счупил нещо, докато сме се опитвали да решим даден проблем? По предишния проект пълен регрешън се правеше за 3 дни от двама тестери. Няма начин да чакаме толкова дълго. За сметка на това добре проектираните юнит тестове ти дават отговор в рамките на минута-минута и половина.
Разбира се обаче, че трябва да има баланс. Аз например никога не пиша юнит тестове за сторнати процедури и ДАЛ. Сторнатите процедури по стандарт трябва да са тъпи и да не съдържат почти никаква логика. ДАЛ имаме готов компонент, за който вече са измислени юнит тестовете и който се пипа само като трябва да се портне към нова версия на фреймуърка (сега се говори да сме го сменяли с Ентити).
Разбира се обаче, че трябва да има баланс. Аз например никога не пиша юнит тестове за сторнати процедури и ДАЛ. Сторнатите процедури по стандарт трябва да са тъпи и да не съдържат почти никаква логика. ДАЛ имаме готов компонент, за който вече са измислени юнит тестовете и който се пипа само като трябва да се портне към нова версия на фреймуърка (сега се говори да сме го сменяли с Ентити).
в отговор на Лaнc Линk - тaйният areнт
#19
Re: TDD употреба
Аз точно затова казах, че мое наблюдение код ревютата са най-неефективни. За сметка на това пеъринг дава много добри резултати - постепенно хората по един проект си уеднаквяват стила, докато в един момент започнат да следват стандартите без дори да се замислят. Много подходящ и при наемане на нови хора да им се покаже "как правим нещата тук". Защото, както се разбра вече, документи никой не чете.
в отговор на Лaнc Линk - тaйният areнт
#20
Re: TDD употреба
<quote>
Автоматични тестове, ръчни тестове, код ревюта, задължителна код конвенция и като капак по един качествен QA.
</quote>
Да, и 100 мармота също, за всеки случай. И едно пони.
Автоматични тестове, ръчни тестове, код ревюта, задължителна код конвенция и като капак по един качествен QA.
</quote>
Да, и 100 мармота също, за всеки случай. И едно пони.