Анкета: Unit tests
47 отговора
0 прегледа
. Тея тестове са готини, но само за малка част от всички проекти. В повечето случаи е важно продуктът да работи криво-ляво, така чи за какво са ни? Особено ако правим проекти със студенти за държавата.
Re: Анкета: Unit tests
Проекта, дето наследявам е 100% юнит-тестнат и минава. И 100% не работи на практика. Учени глави от 2 държави се чешем няколко месеца. Едва тия дни почнах да схващам какво става и взе да се съживява.
Та, 100% булшит е ТДД. Нямаш кейс в анкетата, че не пиша тестове.
Та, 100% булшит е ТДД. Нямаш кейс в анкетата, че не пиша тестове.
Re: Анкета: Unit tests
Аз много обичам да намирам тестове в стар код, които тестват самия mocking фреймуърк. Ей, просто безценни бисери съм виждал. Важното е тестове да има.
Или да откриеш, че нещо работи като е мокнато в тест (OData LINQ Any(), а после ин риал лайф - курац, ама иначе теста минава и всичко е точно.
Или да откриеш, че нещо работи като е мокнато в тест (OData LINQ Any(), а после ин риал лайф - курац, ама иначе теста минава и всичко е точно.
Re: Анкета: Unit tests
Един колега разправя, че познава писател на книги. Написал няколко за софтуерно инженерство. И не написал и един реален проект. "Неграмотните са принудени да диктуват. "
Някаква умна глава накарала всички променливи в кода да са файнъл. Хиляди са. Не можаха да ми обяснят защо. За юнит тестовете вече споменах. Един и същ файл (като име), за конфигване, на различни места в кода, с различни настройки вътре. Всяко обръщение към базата - отваря конекция, вади 10 байта, затваря конекция. Няма 1 ред коментар. А са правили собствена имплементация на ОРМ като Хибернейт. Също нямаше смислено обяснение.
От лели Гани в нашия занаят - дотам я докарахме. Има да изриваме л-на поне няколко месеца, че да изчистим от учените неща.
Споменах ли, че проектът не работеше? А са минали и одитори и са го приели.
Да не отварям приказка за Скумове и Ажайли.
п.с. Да не пропусна основното.
1. Класически вариант. Значи има да се прави нещо. Преборваш естествената човешка реакция - мързел. Правиш.
2. Вариант ТДД.
2.1. Бориш мързела да напишеш теста.
2.2. Стягаш се да направиш каквото там трябва.
2.3. Чешеш се по главата в кое е проблема, че не минава теста.
Значи, ТДД дава в пъти по-голямо натоварване, за единица работа. Което понякога те отказва да я свършиш въобще. Ама звучи учено, и леля ти не знае на практика какво представлява. И натиска да се работи така. На главата ми е в момента, и бера изгнилите плодове. Цели отдели има с такива. И на леля ти дали ново БМВ, вози ни с нея. Другия месец пак ще ходя по чужбинско да им се порадвам.
Някаква умна глава накарала всички променливи в кода да са файнъл. Хиляди са. Не можаха да ми обяснят защо. За юнит тестовете вече споменах. Един и същ файл (като име), за конфигване, на различни места в кода, с различни настройки вътре. Всяко обръщение към базата - отваря конекция, вади 10 байта, затваря конекция. Няма 1 ред коментар. А са правили собствена имплементация на ОРМ като Хибернейт. Също нямаше смислено обяснение.
От лели Гани в нашия занаят - дотам я докарахме. Има да изриваме л-на поне няколко месеца, че да изчистим от учените неща.
Споменах ли, че проектът не работеше? А са минали и одитори и са го приели.
Да не отварям приказка за Скумове и Ажайли.
п.с. Да не пропусна основното.
1. Класически вариант. Значи има да се прави нещо. Преборваш естествената човешка реакция - мързел. Правиш.
2. Вариант ТДД.
2.1. Бориш мързела да напишеш теста.
2.2. Стягаш се да направиш каквото там трябва.
2.3. Чешеш се по главата в кое е проблема, че не минава теста.
Значи, ТДД дава в пъти по-голямо натоварване, за единица работа. Което понякога те отказва да я свършиш въобще. Ама звучи учено, и леля ти не знае на практика какво представлява. И натиска да се работи така. На главата ми е в момента, и бера изгнилите плодове. Цели отдели има с такива. И на леля ти дали ново БМВ, вози ни с нея. Другия месец пак ще ходя по чужбинско да им се порадвам.
Редактирано от rabin на
Що го няма моя отговор - що помага
Безсмисленото гонене на метрики или пък заповед от шефа обикновено не помага, а само товари хората с ненужна работа.
Но има ситуации в които писането на тестове определено помага. Друг е въпроса, че трябва да го осъзнаеш и да го имплементираш като хората.
По тази тема съм писал преди години тука в клубчето - ако ти се рови, може и да намериш.
Но накратко кога и къде ги ползвам и ми спестяват време и нерви.
1. При запис/зареждане на обект от базата.
С необходимата инфраструктура - теста ти е 4 реда код (не броим попълването на поленцата със стойности), пише се за минута, изпълнява се под секунда.
User u = new User();
u.setName("name");
u.setEmail("email");
...
u.save();
User u2 = User.load(u.getId());
assert(u.equals(u2));
Тестваш наведнъж - save, load (ако има find - да кажем по-емайл) и equals - тоя последния обикновено е генериран от средата.
Ако ползваш някво ORM - шансовете за грешки намаляват, но не са изключени.
2. При по-сложната бизнес логика, ако пишеш Уеб Апп пести време.
Дори и да имаш пуснат Апп сървър. Той инвалидира сесията. Трябва да се логваш след всяка промяна. Да навигираш до екрана. Да набиваш разни стойности, да цъкаш Саве бутона и да сверяваш дали са верни резултатите. И това всеки път.
С едно юнит тестче става с натискането на един бутон и минава за под секунда. Кат не ти светне зелено - търсиш грешката.
3. При рефакторинг юнит тестовете също много помагат. Мажеш, рефакторваш, бършеш код, променяш, оптимизираш - спокойно без да се притесняваш. Накрая пускаш теста и спи града и селяните в него.
Но има ситуации в които писането на тестове определено помага. Друг е въпроса, че трябва да го осъзнаеш и да го имплементираш като хората.
По тази тема съм писал преди години тука в клубчето - ако ти се рови, може и да намериш.
Но накратко кога и къде ги ползвам и ми спестяват време и нерви.
1. При запис/зареждане на обект от базата.
С необходимата инфраструктура - теста ти е 4 реда код (не броим попълването на поленцата със стойности), пише се за минута, изпълнява се под секунда.
User u = new User();
u.setName("name");
u.setEmail("email");
...
u.save();
User u2 = User.load(u.getId());
assert(u.equals(u2));
Тестваш наведнъж - save, load (ако има find - да кажем по-емайл) и equals - тоя последния обикновено е генериран от средата.
Ако ползваш някво ORM - шансовете за грешки намаляват, но не са изключени.
2. При по-сложната бизнес логика, ако пишеш Уеб Апп пести време.
Дори и да имаш пуснат Апп сървър. Той инвалидира сесията. Трябва да се логваш след всяка промяна. Да навигираш до екрана. Да набиваш разни стойности, да цъкаш Саве бутона и да сверяваш дали са верни резултатите. И това всеки път.
С едно юнит тестче става с натискането на един бутон и минава за под секунда. Кат не ти светне зелено - търсиш грешката.
3. При рефакторинг юнит тестовете също много помагат. Мажеш, рефакторваш, бършеш код, променяш, оптимизираш - спокойно без да се притесняваш. Накрая пускаш теста и спи града и селяните в него.
Re: Що го няма моя отговор - що помага
Потенциално критичните точки си ги тестваш сам. Без да те кара някой.
Ако разкарат 50% от администрацията по софтуерните фирми - никой няма да усети. Само ще стане по-широко и по-тихо. И няма да налагат безсмислени оперативки.
Има и по-брутални техники - 2-ма кодери с 2 клавиатури на един комп. Екстрийм Програминг. Гане, пиши и предлагай в понеделник. Може да впечатлиш шефа. Тъй се прави кариера и мега СиВи
Ако разкарат 50% от администрацията по софтуерните фирми - никой няма да усети. Само ще стане по-широко и по-тихо. И няма да налагат безсмислени оперативки.
Има и по-брутални техники - 2-ма кодери с 2 клавиатури на един комп. Екстрийм Програминг. Гане, пиши и предлагай в понеделник. Може да впечатлиш шефа. Тъй се прави кариера и мега СиВи
Re: Що го няма моя отговор - що помага
Нали това казвам. Задължителните неща без мисъл - чупят производителността. И не на последно място - мотивацията.
"Защото казвам" - като го чуеш от костюмиран пингвин - след това се влиза по форумите за простеене. Като дойде време да ти държат сметка що не си готов по техните срокове - вече се влиза в жобс.бг
Тая година тоя цикъл го завъртях 2 пъти, не говоря наизуст! От едната фирма дето си заминах - бяхме двама напускащи в рамките на седмица. Третия подал наскоро предизвестие. От старите програмисти остана само един, а са затрупани от работа. Вземат някакви нови и ги учат И май са подписвали неустойки за закъснения към клиента.
Лели Гане, чети...
"Защото казвам" - като го чуеш от костюмиран пингвин - след това се влиза по форумите за простеене. Като дойде време да ти държат сметка що не си готов по техните срокове - вече се влиза в жобс.бг
Тая година тоя цикъл го завъртях 2 пъти, не говоря наизуст! От едната фирма дето си заминах - бяхме двама напускащи в рамките на седмица. Третия подал наскоро предизвестие. От старите програмисти остана само един, а са затрупани от работа. Вземат някакви нови и ги учат
И май са подписвали неустойки за закъснения към клиента.
Лели Гане, чети...
Редактирано от rabin на
Re: Анкета: Unit tests
Винаги ще се пробутват заклинания, които гарантират успешен завършек на софтуерните проекти. Стават модерни за момент и изпадат в забвение. Та юнит тестинга е много близо до това. Дори ще изкажа спекулативно предположение защо не помага - истинските проблеми са в интеграцията на модули/юнити, а не във всеки конкретен от тях. Като груба аналогия, кривата стена пада дори тухлите да са здрави. От друга страна, стабилна стена може да се построи с недялани камъни, ако са напаснати добре.
Ебаси къв дълъг мозък изръсих
Ебаси къв дълъг мозък изръсих
Re: Що го няма моя отговор - що помага
Юнит е - тестваш си метода на класа и нищо повече.
Интегрейшъните са сложнотии. Аз почти не съм видял читава имплементация на това чудо. На повечето места е щото шефа иска.
На времето бях почнал да мисля как може да става това за Уеб Апп и с четене и питане в клубчето (имаше добри идеи от колегите) ми се заформи идея. Даже я реализирах и добре стана. Но си изискваше сериозна поддръжка и го отебах. А на колегите не им се занимаваше.
Архитектурата беше - сървлети четат параметрите, викат разни методи на разни обекти, поставят необходимите обекти в рекуеста и викат JSP да визуализира нещата.
Та идеята беше да се автоматизира това тестване. А реализацията беше едно модулче което билдва заявка с параметри, праща ги ги сървлетите. Поддържа си кукита за сесия и пр. екстри. И после чете каквото му върне Апп-а.
Уеб апп знаеше, че работи в режим на автоматично тестване и вместо да редиректва към JSP-то сериализираше нещата в рекуеста в XML формат и ги пишеше в респонса (20 реда код, 1 параметър и 1 допълнителна библиотека в Аппа). От другата страна - (клиента дето пращаше заявките) имаше десериализатор и той вече проверяваше дали са върнати очакваните обекти и дали са в очаквания стейт.
Добра идея беше - работеше много прилично. Ама си изискваше сериозна поддръжка и сериозно писане на тестове. Обаче на никой не му се занимаваше и така си останаха само 5-6 теста написани от мен.
Интегрейшъните са сложнотии. Аз почти не съм видял читава имплементация на това чудо. На повечето места е щото шефа иска.
На времето бях почнал да мисля как може да става това за Уеб Апп и с четене и питане в клубчето (имаше добри идеи от колегите) ми се заформи идея. Даже я реализирах и добре стана. Но си изискваше сериозна поддръжка и го отебах. А на колегите не им се занимаваше.
Архитектурата беше - сървлети четат параметрите, викат разни методи на разни обекти, поставят необходимите обекти в рекуеста и викат JSP да визуализира нещата.
Та идеята беше да се автоматизира това тестване. А реализацията беше едно модулче което билдва заявка с параметри, праща ги ги сървлетите. Поддържа си кукита за сесия и пр. екстри. И после чете каквото му върне Апп-а.
Уеб апп знаеше, че работи в режим на автоматично тестване и вместо да редиректва към JSP-то сериализираше нещата в рекуеста в XML формат и ги пишеше в респонса (20 реда код, 1 параметър и 1 допълнителна библиотека в Аппа). От другата страна - (клиента дето пращаше заявките) имаше десериализатор и той вече проверяваше дали са върнати очакваните обекти и дали са в очаквания стейт.
Добра идея беше - работеше много прилично. Ама си изискваше сериозна поддръжка и сериозно писане на тестове. Обаче на никой не му се занимаваше и така си останаха само 5-6 теста написани от мен.
Re: Що го няма моя отговор - що помага
Искаш да кажеш, че се абстрахираш от базата и си тестваш само метода?
ОК, това е вече юнит, ама аз не разбирам какво толкова тогава му тестваш на метода User.load() или User.find() примерно?
В 99.9% от слуаите в този метод имаш само 2 неща:
1.Get the data from database
2.Map that data to object
Първото не го тестваш... кво му тестваш тогава на второто?
Имам впредвид, че аз лично в случая не виждам никакъв смисъл да се тества това.
ОК, това е вече юнит, ама аз не разбирам какво толкова тогава му тестваш на метода User.load() или User.find() примерно?
В 99.9% от слуаите в този метод имаш само 2 неща:
1.Get the data from database
2.Map that data to object
Първото не го тестваш... кво му тестваш тогава на второто?
Имам впредвид, че аз лично в случая не виждам никакъв смисъл да се тества това.
Re: Анкета: Unit tests
Не е много приятно да се пишат юнит тестове върху нашата система конкретно, но се изисква от "горе", затова гласа ми е за "шефа". Някой път е полезно, защото се виждат проблеми в имплементацията.
Нашата система има прекалено много конфигурационни файлове, които са имплементация на филтри в пайпс, на декорейтъри, на депенденси инджекшънс, на месидж ексчейндж патернс и подобни. После имаме много бизнес рулз файлс, които се изпълняват от рулз енджин. После имаме един тон XSL. С# кода прекалено често навързва всичко и самостоятелно няма какво толкова да му тестваш...но се налага. Някой път фрънт енд кода по-има смисъл да се тества и е полезно, но в повечето случай си е мъчение.
Нашата система има прекалено много конфигурационни файлове, които са имплементация на филтри в пайпс, на декорейтъри, на депенденси инджекшънс, на месидж ексчейндж патернс и подобни. После имаме много бизнес рулз файлс, които се изпълняват от рулз енджин. После имаме един тон XSL. С# кода прекалено често навързва всичко и самостоятелно няма какво толкова да му тестваш...но се налага. Някой път фрънт енд кода по-има смисъл да се тества и е полезно, но в повечето случай си е мъчение.
в отговор на pesho.konia
#20
Re: Анкета: Unit tests
Добре Пеше, започни сега бавно, убаво и отначало.
Заеби ги конфигурационните файлове, DI, и така нататък...
Въпросът е: Колко юнит тестове си написал, които наистина, ама наистина имат смисъл?
Дай ми един реален пример от последния си юнит тест, който ти си писал и тоя юнит тест е покрил някаква функционалност?
Абстрактни глупости не ми се четат. Каравачева и Наков са ми достатъчно абстрактни...Влез в детайлите и ни обясни някои неща...
Заеби ги конфигурационните файлове, DI, и така нататък...
Въпросът е: Колко юнит тестове си написал, които наистина, ама наистина имат смисъл?
Дай ми един реален пример от последния си юнит тест, който ти си писал и тоя юнит тест е покрил някаква функционалност?
Абстрактни глупости не ми се четат. Каравачева и Наков са ми достатъчно абстрактни...Влез в детайлите и ни обясни някои неща...