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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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