Защо не искаме да пишем Unit Tests
Ето, днес си говорихме с Дешев и един друг приятел по ICQ, защо програмистите не пишат Unit Tests. Не че стигнахме до някакви изводи, обаче ще изредя тия за които се сещам че посменахме:
1. не знам какво е Unit Test и не знам как се пише
2. мързи ме
3. нямам време за тестове
4. ами нали си имаме QA
5. ми то няма голяма полза от тях
6 . ....
Моята е комбианция от всичките изброени май ... някакво смътно гадно чувство - ама сега гледай колко много допълнително писане ми се отваря, и за кво е всичкото това, като утре може всичко да се смени, ама наистина ли всичко трябва да тествам .... и като се замисля за всички тия неща и почвам да се отказвам.
Пък чесно казано понякога е толкоз просто и лесно. Просто решавам че наистина ще пиша тестове и си ги пиша и съм много доволен. Но кое ме кара да правя едното и кое другото - чесно казано не знам. Може би е толкоз простичко като ... just do it.
А твоята/вашата причина коя е? Коментар?
1. не знам какво е Unit Test и не знам как се пише
2. мързи ме
3. нямам време за тестове
4. ами нали си имаме QA
5. ми то няма голяма полза от тях
6 . ....
Моята е комбианция от всичките изброени май ... някакво смътно гадно чувство - ама сега гледай колко много допълнително писане ми се отваря, и за кво е всичкото това, като утре може всичко да се смени, ама наистина ли всичко трябва да тествам .... и като се замисля за всички тия неща и почвам да се отказвам.
Пък чесно казано понякога е толкоз просто и лесно. Просто решавам че наистина ще пиша тестове и си ги пиша и съм много доволен. Но кое ме кара да правя едното и кое другото - чесно казано не знам. Може би е толкоз простичко като ... just do it.
А твоята/вашата причина коя е? Коментар?
posted by boko at 8:50 AM
5 Comments:
Странно. Тази тема е дискутирана на extremeprogramming листата, дори съм участвал в дискусията. И естествено съм забравил. Добре, че постващата Кей Пентекост е събрала резултатите на уикито на Уорд Кънингам -- More Objections To Working Test First.
А знаеш ли дали някъде има реални статистики относно това кои от причините са най-често срещани, някакви анкети или нещо подобно?
Предполагам ето как разсъждават някои от програмистите не зачитащи Unit Tests:
"Имам самочувствието, че като добър програмист пиша качествен код. А ако изскочи случайно някое бъгче, сигурно съм достатъчно умен да го локализирам бърз и с един debug или само с преглед на кода да видя где съм сгафил и да го фиксирам за минутки."
Всъщност донякъде съм съгласен че, ако локализацията и фиксирането на бъга става бързо, то писането на тестове изглежда твърде голям overhead от гледна точка на време. Просто може да не се отплати (поне в рамките на deadline-а за проекта). Е ако системата ще се развива и надгражда, но кой мисли за това в дългосрочен план определено се отплаща, но кой ти мисли за това.
Разбира се, рискът за проекта се увеличава без Unit Tests, но на доста места в процеса на разработка могат да се допуснат къде-къде по-големи рискове.
Имам си и един пример от реален проект (там бях предимно страничен наблюдател), където не само не беше писан нито един unit test ами и почти до края на проекта не се интегрираше нищо. Просто базовите класове, на което трябваше да стъпи всичко, не бяха тествани ама хич. Като бях включен на пожар да помагам там, искаха да пиша unit tests. А само с един бърз code review на кода открих и фиксирах десетки грешки, които за да ги хвана с unit tests щяха да са ми нужни десетки дни. Изводът: ако всичко останало в процеса на разработка ти е наред, тогава мисли за unit tetst.
А според мен в преобладаващ процент от случаите пишем код, който до голяма степен е тривиален и не сме достатъчно мотивирани да влагаме време и в Unit Tests. Аз лично в последните си проекти понаписвам някой друг такъв тест, но само за тези компоненти от приложението, които са наистина комплексни или критични.
Но се получава така, че ако само един от екипа си пише automated tests, то ползата от тях спада значително. Ти си си свършил работата, ама ако системата не бачка, какво значение има кой е виновен. Е това е още една причина да ми спадне ентусиазъма. Тъжно, но факт.
Най-често срещания отговор който аз съм получавала на въпроса "Защо да не си напишем [Unit] тестове за този бъг"
- "Е ..., то тия моите неща няма как да се тестват!"
- "Ще ти покажа, как съм тествала аз, много бъгове се хващат навреме."
- " Е те твоите неща са други, лесни са за тестване, моите не стават."
Не знам дали искам да го коментирам това. Предполагам че не съм избрала хора които са готови да чуят това, което искам да им кажа.
Здравей Chewi, това последното е много интерсно като феномен. Значи от една страна искаме да имаме тестове поради ред причини да речем, а от друга нашия код не става за тестване. Ами без да се опитаме да пишем тестове за кода, как ще разберем дали става за тестване или не? И какво означава по дефиниция - тоя код не става за тестване? Че е трудно да се тества не отричам, но чак не възможно? Дали това е по-скоро незнание какво точно искаме да тестваме, а не как? Т.е. не да речем как точно работи един TestCase, какво точно да пишем в setUp и teadDown, а по-скоро какво от семантиката на даден клас искаме да тестваме?
С други думи не знаем как да го напишем теста (тестовете) а не какво е TestCase и т.н.?
Post a Comment
<< Home