Какви са някои от причините, поради които един единствен разработчик трябва да използва TDD? [затворено]

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

Това е правилното отношение. Използвам TDD през цялото време, но не го спазвам толкова стриктно като някои.

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

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

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

РЕДАКТИРАНЕ: Мога ли да добавя, че ако е направено правилно, всъщност можете да генерирате спецификации за вашия софтуер в същото време, когато пишете тестове. Това е страхотен страничен ефект на BDD. Можете да направите така, че да изглеждате като супер разработчик, ако изработвате солиден код заедно със спецификациите, изцяло сами.

Добре, мой ред... бих направил TDD дори сам (за код без шипове/експериментален/прототип), защото

• Мисли преди да скочиш: принуждава ме да мисля какво искам да свърша, преди да започна да въвеждам код. Какво се опитвам да постигна тук... 'Ако приема, че вече имам това парче... как бих очаквал да работи?' Насърчава интерфейсния дизайн на обекти.
• По-лесен за промяна: Мога да правя модификации с увереност.. „Не съм нарушил нищо в стъпка 1-10, когато промених стъпка 5.“ Регресионното тестване е мигновено
• Появяват се по-добри дизайни: Открих, че се появяват по-добри дизайни, без да инвестирам усилия в дизайнерска дейност. test-first + Рефакторингът води до слабо свързани, минимални класове с минимални методи.. без свръхинженеринг.. без YAGNI код. Класовете имат по-добри публични интерфейси, малки методи и са по-четими. Това е нещо като дзен... забелязваш, че си го получил едва когато го „разбереш“.
• Програмата за отстраняване на грешки вече не е моята патерица: Знам какво прави програмата ми... без да се налага да прекарвам часове в преминаване през собствения си код. В днешно време, ако прекарам повече от 10 минути с програмата за отстраняване на грешки... умствените аларми започват да звънят.
• Помага ми да се прибера навреме Забелязах значително намаляване на броя на бъговете в моя код след TDD.. дори ако твърдението е като проследяване на конзола, а не тип xUnit AT.
• Производителност/поток: помага ми да идентифицирам следващата отделна бебешка стъпка, която ще ме отведе към завършеното... поддържа снежната топка. TDD ми помага да вляза в ритъм (или това, което XPers наричат ​​поток) по-бързо. Получавам по-голяма част от качествената работа за единица време, отколкото преди. Цикълът червено-зелено-рефактор се превръща в... един вид вечен двигател.
• Мога да докажа, че кодът ми работи с едно натискане на бутон
• Практиката прави перфектния Откривам, че уча и забелязвам дракони по-бързо.. с повече време за TDD в колана ми. Може би дисонанс.. но чувствам, че TDD ме направи по-добър програмист, дори когато не отида да тествам първо. Откриването на възможности за рефакторинг стана втора природа...

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

Аз също съм програмист на договор. Ето моите 12 причини, поради които обичам модулните тестове.

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

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

От логическа гледна точка всеки код, който пишете, трябва да бъде тестван и без TDD тогава ще го тествате сами ръчно. От обратната страна на pyftpdlib, най-лошият код по брой грешки и честота на големи проблеми, е код, който е/беше тестван единствено от разработчиците и QA, изпробващи ръчно нови функции. Нещата не се тестват поради липса на време или падане през пукнатините. Старите кодови пътеки са забравени и дори най-старите стабилни функции в крайна сметка се повреждат, основните версии завършват с нефункционални важни функции. и т.н. Ръчното тестване е критично важно за проверката и известно рандомизиране на тестването, но въз основа на моя опит бих казал, че е от съществено значение да има както ръчно тестване, така и внимателно изградена рамка за единичен тест. Между двата подхода пропуските в покритието са по-малки и вероятността от проблеми може само да бъде намалена.

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

Както и да е, TDD не зависи от соло или екипна среда. Зависи от приложението като цяло.

Нямам голям опит, но имах опит да виждам рязко контрастиращи подходи към тестването.

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

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

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

Само моите $0,02.

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

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

TDD не е за тестване, а за писане на код. Като такъв, той предоставя много предимства дори на един разработчик. За много разработчици е промяна в съзнанието да напишат по-стабилен код. Например, колко често си мислите "Сега как може този код да се провали?" след писане на код без TDD? За много разработчици отговорът на този въпрос е никакъв. За практикуващите TDD той пренасочва мисленето към правене на неща като проверка дали обектите или низовете са нулеви, преди да направят нещо с тях, защото пишете тестове, за да направите това конкретно (разбийте кода).

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

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

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

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

Например TDD ви спестява време за тестване/поправяне на грешки в дългосрочен план, а не в рамките на 5 минути след като сте създали първия тест на единица.

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

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

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

Трябва да имате предвид ДРУГИ хора, когато правите нещо. Трябва да мислите напред, да планирате растеж, да планирате устойчивост.

Ако не искате да правите това - придържайте се към каубойското кодиране, така е много по-лесно.

P.S. Същото важи и за други практики:

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

и т.н. до безкрайност

Вече не преработвам нищо без разумен набор от единици тестове.

Не правя пълен TDD с модулни тестове първо и код второ. Правя CALTAL -- Малко кодиране, малко тестване -- разработка. Обикновено кодът е на първо място, но не винаги.

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

Преработвам важните части. Вземете съществуващия набор от тестове за преминаване.

Тогава осъзнах, че съм забравил нещо, и се върнах към разработката на CALTAL за новите неща.

След това виждам неща, които съм забравил да изтрия -- но те наистина ли са неизползвани навсякъде? Изтрийте ги и вижте какво се проваля при тестването.

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

За соло летене TDD е моят втори пилот.

TDD ми позволява по-ясно да дефинирам проблема в главата си. Това ми помага да се съсредоточа върху прилагането само на необходимата функционалност и нищо повече. Също така ми помага да създам по-добър API, защото пиша „клиент“, преди да напиша самия код. Мога също така да преработвам, без да се притеснявам, че ще счупя нещо.

Ще отговоря на този въпрос доста бързо и се надявам, че ще започнете да виждате част от мотивите, дори ако все още не сте съгласни. :)

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

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

Надявам се, че този много опростен пример ще бъде достатъчен, за да ви накара да мислите за TDD малко повече и че може да предизвика искра, която да ви накара да обмислите използването му. Разбира се, ако все още не виждате смисъла и сте уверени в собствените си способности да следите много хиляди редове код, тогава няма къде да ви кажа, че трябва да започнете TDD.

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

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

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

Когато тестовете се провалят, те са възможности да разгледате тях и производствения код и да се уверите, че е правилен. Понякога дизайнът се променя и тестовете трябва да бъдат модифицирани. Понякога ще напиша нещо, което преминава 99 от 100 теста. Този 1 тест, който не е преминал, е като колега, който преглежда моя код (в известен смисъл), за да се увери, че все още изграждам това, което трябва да изграждам.

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

..историята на живота ми през последните 6 месеца. :-/

Единственият разработчик трябва да използва TDD в своя проект (досиетата нямат значение), тъй като в крайна сметка този проект може да бъде предаден на друг разработчик. Или могат да бъдат привлечени повече разработчици.

На новите хора ще им е много трудно да работят с кода без тестовете. Те ще счупят нещата.

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

Мисля, че TDD като методология не е само "да имаш тестове при извършване на промени", следователно не зависи от екипа - нито от размера на проекта. Става дума за отбелязване на нечии очаквания за това какво прави част от код/приложение, ПРЕДИ човек да започне наистина да мисли за това КАК се прилага отбелязаното поведение. Основният фокус на TDD е не само наличието на тест за писмен код, но и писането на по-малко код, защото просто правите това, което прави теста зелен (и рефакторинг по-късно).

Ако сте като мен и ви е доста трудно да мислите какво прави част/цялото приложение, БЕЗ да мислите как да го приложите, мисля, че е добре да напишете теста си след кода си и по този начин да оставите кода да „задвижва“ тестове.

Ако въпросът ви не е толкова за тестване първо (TDD) или тестване след (добро кодиране?), Мисля, че тестването трябва да бъде стандартна практика за всеки разработчик, независимо дали сам или в голям екип, който създава код, който остава в производството повече от три месеца. Според моя опит това е периодът от време, след който дори оригиналният автор трябва да се замисли добре какво всъщност правят тези двадесет реда сложен, супер оптимизиран, но оскъдно документиран код. Ако имате тестове (които покриват всички пътища през кода), има по-малко за мислене - и по-малко за ERR, дори години по-късно...

Ето няколко мемета и моите отговори:

„TDD ме накара да се замисля как ще се провали, което ме направи по-добър програмист“

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

„Приложенията трябва да работят правилно“

Това предполага, че можете да тествате абсолютно всичко. Няма да сте по-добри в правилното покриване на всички възможни тестове, отколкото в първоначалното правилно писане на функционалния код. „Приложенията трябва да работят по-добре“ е много по-добър аргумент. Съгласен съм с това, но е идеалистично и не е достатъчно осезаемо, за да мотивира толкова, колкото ми се иска. Метриките/анекдотите биха били чудесни тук.

„Работи чудесно за моя ‹библиотечен компонент X›“

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

„Помислете за следващия разработчик“

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

Колко ще оцените проектите, направени в отхвърлени задължителни методологии, когато наследите такава? RUP, някой? Помислете какво означава TDD за следващия разработчик, ако TDD не е толкова страхотен, колкото всички го мислят.

„Рефакторингът е много по-лесен“

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

...

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

Мотивиран личен интерес.

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

С течение на времето тази библиотека се разраства и се използва в повече проекти за различни клиенти. Тестването отнема повече време. Особено случаите, в които (надявам се) поправям грешки и (още повече се надявам) да не счупя нещо друго. И това не е само за грешки в моя код. Трябва да внимавам с добавянето на функционалност (клиентите продължават да искат още „неща“) или да се уверя, че кодът продължава да работи, когато се премести в нова версия на моя компилатор (Delphi!), код на трета страна, среда за изпълнение или операционна система.

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

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

В крайна сметка това означава по-малко време за поддръжка и повече време за правене на неща, които са по-печеливши, по-интересни (почти всичко) и по-важни (като семейството).

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

Когато става дума за добър шофьор на автомобил, всеки вярва, че е „добър шофьор“. Това е когнитивно отклонение, което имат всички шофьори. Програмистите имат свои собствени пристрастия. Причините, поради които разработчиците като OP не правят TDD, са разгледани в тази Поредица от подкасти за Agile Thoughts. Архивът на подкаста също така съдържа съдържание относно концепции за автоматизация на тестове, като например тестова пирамида и въведение за това какво е TDD и защо първо да пишете тестове, започвайки с епизод 9 в подкаст архива.