Разговор със Стефан Кънев за TDD (Test Driven Development). Дали TDD е мъртво, или непрактично? Кога и как трябва да се използва, какви са затрудненията, какво трябва да се има предвид и много други полезни неща и съвети.
Директен линк към част 2 (mp3) (ogg)
Материали по темата:
Презентацията на DHH:
https://www.youtube.com/watch?v=9LfmrkyP81M
Блог постовете по въпроса:
http://david.heinemeierhansson.com/2014/tdd-is-dead-long-live-testing.html
http://david.heinemeierhansson.com/2014/test-induced-design-damage.html
http://david.heinemeierhansson.com/2014/slow-database-test-fallacy.html
Опровержението:
https://www.destroyallsoftware.com/blog/2014/test-isolation-is-about-avoiding-mocks
https://www.destroyallsoftware.com/blog/2014/tdd-straw-men-and-rhetoric
Антитезата:
http://www.infoq.com/presentations/integration-tests-scam
Дискусиите м/у DHH, Kent Beck и Martin Fowler:
http://martinfowler.com/articles/is-tdd-dead/
Книгата за TDD:
http://www.amazon.com/Test-Driven-Development-By-Example/dp/0321146530
юли 27th, 2014 at 22:50
Я още един епизод с моя полукумир сред презентьорите кАнев. Ура! Интересно е, какво ще добави от лекцията на бургаската конференция. С нетърпение чакам утре а мога да го изслушам.
юли 29th, 2014 at 00:47
Много ми хареса тази „лекция“ 🙂
Избистриха ми се доста неща, които ми бяха малко мътни.
Най-важното е, че за всеки проект има различен подход и не е важно просто да се свърши работата, ами да се избере правилното нещо за дадената ситуация (това включва и писането на тестове).
Интересно е когато човек има опит – тогава е по резервиран и не набляга на крайните твърдения. Просто за всяка една конкретна ситуация може да има няколко добри решения или пък точно обратното – може да няма и едно достатъчно добре решение.
За мен лично също е леко трудно с да пиша тестове, защото се опитвам да мисля за коректно и смислено покриване (coverage), но определено се вижда разлика, когато има тестове (няма да коментирам дали тази разлика е положителна или отрицателна).
Та в програмирането винаги е така – винаги има trade off.
Благодаря за този епизод & keep going!
юли 29th, 2014 at 12:08
И на мен много ми хареса подкаста, много добра дискусия се получи.
юли 29th, 2014 at 15:45
Значи .. според мен testinga е МЪСТ.
ся дали е ТДД или не… аз лично не смятам че ставам за TDD щото нещата който ги пиша рядко знам как ще се напишат. Според мен TDD не работи като се прави ресърч.
Все пак смятам че колкото тестове толкова по добре и че под 60% code coverage си е подигравка и подобен проект трябва да бъде изтрит и забравен.
Ще обясня и защо.
Много хора работят по outsourcing фирми.. там естествено .. пука ти .. режи мажи.. след 6 месеца максимум година я си по друг проект я си напуснал никой не му пука… естествено в такива проекти… testing is for sissies както беше казал един колега Patrick Ohl.
Обаче… ако работиш по продукт нещата са различни и веднага ще обясня защо.
Имаш продукт.. имаш много хора.. и имаш release или версия на всеки.. 3 месеца. Обикновенно продуктите вървят с фиксирано време между версиите… било то 3 било то 4 или 12 месеца. Факт е че на всяка версия ти трябва да видиш преди да пуснеш дали всичко работи и сега ето какво се получава.
Вариант 1:
– нямаш тестове или .. по скоро имаш ама под 50%
– имаш 3 месеца development .. проблема е че за да изтестваш цялата си функционалност ти трябват 3 седмици… 3 седмици безкрайно цъкане на QA и last minute fix-ване на девелопъри за да е сигурно че няма да се пуснат 3 хотфикса веднага след release.
-изведнъж се оказва че ти имаш 2 месеца и седмица development ама няма нищо…
Пускаш всичко работи.
Версия 2… пак 3 месеца девелопмънт така де 2 .. и 3 седмици тестване.. работи
Пускаш пак …
Проблема е че със всяка нова версия времето за тестване расте.. в един момент ще са ти нужни 4 седмици .. а може би .. месец и седмица в един момент вече минаваш.. на версия на всеки 6 месеца.. щото 2 месеца тестваш… (мисля че се вижда проблема).. в един момент или нищо не релиизваш .. или релиизваш бавно.. или релиизваш на 3 месеца ама девелопмънта ти е 1 седмица: Д
Вариант 2: имаш над 80% code coverage. . било то с Unit testove + Integraiton Testove + Functional testove важното е че имаш тия 80%.
пишеш до 3 дни преди релииз.. проверяваш за 1 ден най най новите неща които си писал и за, които може би има тестове но не си сигурен че са достатачно добри.. дописваш още няколко test case-а … казваш на маркетинга да ъплоадват .. 2 дни планираш и си гледаш facebooka.. имаш 2 месеца и 3 седмици и 2 дни development. След 1 версия.. имаш същото време.. след 100.. имаш същото време..
Thats all.
юли 29th, 2014 at 22:56
Напълно съм съгласен с JOKe, естествено, че автоматичното тестване е задължително, наскоро го осъзнах и мисля, че мнението ми дълго време ще остане такова.
Как разбираш една сложна система дали работи правилно без да направиш тестове? Никак. Кое е по-лесно ръчни тестове за 150 случай или автоматични? Автоматични. Мисля че и до тук да спра ще е достатъчно.
Как разбираш след като промениш един компонент, който е dependency на 20 други компонента, дали тези компоненти работят? Като тестваш, ама хайде тествай 100 различни сценария на ръка..
На програмиста се дава задание да накара компютъра да направи конкретно нещо, тоест като се въведете това и това да върне това и това, рядко е толкова просто, но нещата се свеждат до там.
август 1st, 2014 at 15:59
Забелязвате ли, че Стефан е първият повторил се гост?
Стана ми интересно, че Стил твърдеше, че темата е скучна до приспивност, пък в разговора беше доста активен.
Вярвам всеки си е извел своя извод от разясненията на участниците. Още един перфектен епизод!
август 2nd, 2014 at 13:53
Този пост е нагледен професионализъм. Благодаря!
август 7th, 2014 at 23:28
Да напишеш тестове преди да си напасъл кода
е все едно
Да се опитваш да видиш грешки които още не си допуснал , тоест струва ми се абсурдно ….да може би писането на тестове преди кода ще фокусира вниманието ти върху проблемните варианти или върху повече варианти , но ще ти отнеме от времето/вниманието нужно за едно по добро изграждане на кода ….
август 8th, 2014 at 17:50
Основната цел на тестовете не е да си намериш грешки, а да предотвратиш регресии. Също така идеята на писането на тестове предварително е да се види как ще се използва API-то за да може да се напише по-правилно.
август 8th, 2014 at 20:28
Също съм на мнение, че тестовете са хубаво нещо, но все пак зависи от проекта. Ако е публичен и се използва/пише от много хора, смятам че е доста добра идея. Така например когато човек компилира php от сорса, има опция за make test след make-а с над 9000 теста. Изтестваш го и ти казва това работи, това не, и дава опция да се прати на разработчиците за фийдбак. Колко яко е това? Отделно един тест се пише един път [може да се наложи да се преправя, зависи колко е generic], но после се тества милиони пъти на 100ци хиляди различни конфигурации.