|
|
Страници по тази тема: 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | (покажи всички)
|
|
|
1. Тест първо ме кара да мисля малко повече, преди да напиша поредната глупост.
Архитектурата и дизайна са това което те кара да мислиш предварително и предпазва от правене на глупости.
2. За да мине теста, пиша минималното количество код. Тоест поддържам по-малко код, което не е малко :)
Това не го разбрах - в кода или в кода на теста? Повечето код и допълнителните екстри надали ще ти свалят теста - не и ако са написани качествено.
3. Често докато пиша теста се сещам за следващия тест - друг сценарий, който трябва да покрия - гранични случаи например.
Ако го пишеш след като кода е готов тези неща вече ще си ги мислил един път докато пишеш и ще ти е по-лесно да измислиш повече тестове.
Моя аргумент го казах преди - тестовете дублират работата по дизайн документите и за разлика от тях не стават толкова лесно за ревюта. След това по време на работа като се наложи дори и минимална промяна трябва да се ъпдейтва и теста - допълнителна работа която може да се спести, ако теста се пише след като вече имаш пълната информация какво и как да тестваш, а именно след като кода е готов.
----------------------------------------
Здрав дух, в здрава бутилка!
| |
|
|
|
Само да те питам, ти доволен ли си от качеството на тестовете като ги пишете след като сте събрали димящата купчина код? Щото хората дето пишат тестовете предварително изглеждат доста happy, ама може само да се правят.
| |
|
|
|
В отговор на:
Архитектурата и дизайна са това което те кара да мислиш предварително и предпазва от правене на глупости.
Точно така. Тестовете са просто конкретната манифестация на парченцето архитектура или дизайн, които имплементираш в момента. (Свалям шапка в посока на BDD темата)
Писането на тестове след кода е ужасна мъка, защото обикновено кодът е писан без грам замисъл за тестваемост. На такъв код му викам "legacy" или просто "боклук". Никой не иска да пише тестове за код, който зависи от сесията на уеб приложение, събитие от мишка на десктопа и т.н.
При TDD тестваемостта ти е гарантирана и наистина, както каза wqw, имаме повече усмивки. Аз обикновено разписвам тест, правя го зелен, пиша нов тест, озеленявам отново и т.н. В един момент виждам, че сякаш имам функционалността, която преследвам. Ако се сетя за някой граничен случай или изкривен сценарий, нищо не ми пречи да напиша допълнителен тест за него. И това няма да ми е трудно.
| |
|
|
|
<<EOQ
1. Тест първо ме кара да мисля малко повече, преди да напиша поредната глупост.
2. За да мине теста, пиша минималното количество код. Тоест поддържам по-малко код, което не е малко :)
3. Често докато пиша теста се сещам за следващия тест - друг сценарий, който трябва да покрия - гранични случаи например.
EOQ
Винаги ми е звучало екстра това на теория, но дори като се опитвам да съм
дисциплиниран правоверен, накрая заебавам и си карам както знам. В крайна сметка тестовете подпомагат хавата, не я движат (движи я талибана дето пише безсмислени тестове ).
Харесвам инструменти, които нямат против, че съм кретен и използвам каквото ми е сгодно в момента.
| |
|
|
|
Когато са написани тестове - да. За съжаление не винаги има, но напоследък ставаме по-дисциплинирани.
----------------------------------------
Здрав дух, в здрава бутилка!
| |
|
|
|
"Писането на тестове след кода е ужасна мъка, защото обикновено кодът е писан без грам замисъл за тестваемост" - кода си има цел, а ти тестваш целта, тя е винаги тестваема
Повечето усмивки се базират на съвсем други неща, освен това е доста трудно да го докажеш, защото става дума за субективни фактори и възприятия.
Да си напишеш кода добре не зависи от процес, а от човек.
----------------------------------------
Здрав дух, в здрава бутилка!
| |
|
|
|
Тук вече навлизаме във философски размисли. Обаче като се тегли чертата, ползите от ТДД са повече, отколкото без ТДД.
Стана ми интересно, че никой не засегна другия аспект на ТДД - дизайн. Ако се пишат както трябва, крайните "тестове" не само показват какво трябва да прави "тестваемия" код, ами и как трябва да изглежда. Както някой написа по-горе - код писан без ТДД е трудно тестваем. Но не това е най-важното в случая. По-важно е, че същия този код е силно свързан с изкуствени зависимости. Това е причината пост-фактум юнит тестовете да са трудни за измисляне.
| |
|
|
|
Ние опитахме по един проект БДД. С две думи - не е лесно. Най-трудното беше да се накарат клиентите да седнат на масата (образно казано) и да обяснят подробно какво аджеба се иска. Като че ли това е и най-трудната част от всеки проект по принцип - да се определят критериите за "приемливост". Следващата трудност беше тези критерии да се вкарат в "изпълними" тестове. Опитахме с Фитнессе, но нещо не проработи както трябва. Автоматизираните тестове също не дадоха кой знае какъв резултат. В крайна сметка процеса се сведе до обичайните ръчни тестове + юнит тестове.
Та на пръв поглед идеята на БДД е доста интересна - да се изкарат юнит тестовете на по-високо ниво. Но на практика за нас се оказа неприложима.
| |
|
|
|
Изкарвам обратния резултат като тегля чертата
Дизайна се прави на документ с картинки и е много по-читаем от тестовете, защото идеята на дизайна не е само да не се отплеснеш на някъде, но и да провериш нещата с дизайнери, шефове и клиенти преди да си ги почнал.
----------------------------------------
Здрав дух, в здрава бутилка!
| |
|
|
|
И после, след като са надлежно прегледани, поправени и прошнорувани, да се хвърлят на боклука, щото нещо, което на хартия е изглеждало супер, на практика се оказва не чак толкова добра идея (меко казано).
Не знам при вас как са нещата, но по нашите проекти дизайна се променя до последните една-две седмици. Накрая се стабилизира. До преди две години проектите бяха РУП, с дълга фаза на дизайн. Всички до един отидоха по дяволите. В един момент започнахме да вкарваме Аджайл тук-таме (ТДД беше сред първите техники) и мога да кажа, че разликата при нас е очевадна.
| |
|
Страници по тази тема: 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | (покажи всички)
| 
|
|
[