tag:blogger.com,1999:blog-6313277656544247723.post9047461432959058566..comments2023-10-11T19:36:37.977+06:00Comments on Goblin Game: О вреде и пользе регрессионных тестовСергей Высоцкийhttp://www.blogger.com/profile/01289041631095569954noreply@blogger.comBlogger5125tag:blogger.com,1999:blog-6313277656544247723.post-82705063923101267862011-10-01T20:20:55.310+07:002011-10-01T20:20:55.310+07:00Можно переубеждать, а можно просто взять денежку и...Можно переубеждать, а можно просто взять денежку и сделать чего просят. Первое сложно, второе некрасиво (зато почти mortgage driven development).<br /><br />С другой стороны есть тот же фейсбук, где автоматические проверки прав доступа через GUI более чем оправданы. Но это уже скорее специфика проекта.Сергей Высоцкийhttps://www.blogger.com/profile/01289041631095569954noreply@blogger.comtag:blogger.com,1999:blog-6313277656544247723.post-72684526868349974962011-10-01T13:28:06.877+07:002011-10-01T13:28:06.877+07:00Да-да, вот только по опыту очень сложно объяснить ...Да-да, вот только по опыту очень сложно объяснить клиенту/менеджеру, что писать автоматические тесты на длинную цепочку операций с UI - нецелесообразно и затратно. "Selenium чё," - говорят в ответ - "значит квалификации недостаточно"Anonymoushttps://www.blogger.com/profile/09085009462585036025noreply@blogger.comtag:blogger.com,1999:blog-6313277656544247723.post-32214807296533767382011-10-01T06:33:01.049+07:002011-10-01T06:33:01.049+07:00Автоматизируемо в принципе все. Были бы время и де...Автоматизируемо в принципе все. Были бы время и деньги. Минимальный набор простых и быстрых тестов с элементарными оракулами как правило более чем достаточен. Дальше от специфики проекта зависит.<br />Про дублирование unit test'ов все просто. Например писать кучу тестов которые заполняют форму и жмакают кнопочку submit как правило не имеет смысла, т.к. на уровне кода/апи эти случаи покрываются куда проще и делают все то же самое куда быстрее. Аналогично с валидаторами полей. Аналогично с загрузкой картинок. Не всегда, но как правило.<br /><br />В регрессионных тестах ничего плохого нет, если без фанатизма. Просто вспоминаем про 6-15% и думаем насколько пропорциональные усилия мы прилагаем. В том числе и в плане автоматизации. Ведь автоматизация регрессионных тестов это далеко не единственная возможная задача автоматизации тестирования в принципе.<br />Опять же - плохие регрессионные тесты могут быть как ручными. Избыточные проверки вида "проверим каждый баг который когда-либо случался" это плохие регрессионные тесты. Жесткие сценарные тесты в регрессии кроме как автоматические change detector'ы как правило тоже не оправданы. А вот набор тестов для быстрого обнаружения ухудшения качества вполне ок.<br /><br />Опять же - регресс продукта это неприятно. Но те проблемы которые могут быть обнаружены тестами которые мы никогда не выполняли не менее неприятныСергей Высоцкийhttps://www.blogger.com/profile/01289041631095569954noreply@blogger.comtag:blogger.com,1999:blog-6313277656544247723.post-35021046536083533542011-10-01T02:50:29.688+07:002011-10-01T02:50:29.688+07:00Автоматизируем регрессионные тесты и радуемся полу...Автоматизируем регрессионные тесты и радуемся получаемым результатам. Не все правда, а только те, которые "автоматизируемы"...<br />Насчет дублирования Unit-тестов не совсем понял. Юнит-тестам свои цели , время и место в цикле разработки.. Регрессионным тестам функциональности(автоматическим или ручным) - свое. Более того, в динамично развивающихся продуктах никак нельзя ни без unit ни без регресса тестирования уже имеющейся ранее функциональности...willhttps://www.blogger.com/profile/02812813329963523314noreply@blogger.comtag:blogger.com,1999:blog-6313277656544247723.post-64381766811359229922011-10-01T01:35:23.927+07:002011-10-01T01:35:23.927+07:00Хыхы, я потом спрошу у тебя про наш случайХыхы, я потом спрошу у тебя про наш случайAnonymousnoreply@blogger.com