tgoop.com/dev_easy_notes/395
Last Update:
Итак, снепшот тесты. Тесты когда мы отрисовываем интерфейс, сравниваем его по пикселям с эталоном и падаем, если картинка сильно отличается.
Я на практике много раз убеждался, что такие тесты нужны иссключительно командам, которые занимаются дизайн-системами. В таких командах действительно важно, чтобы при изменениях в кнопке всё не поехало. Если они выпустят новую версию UI Kit с таким багом, кривая кнопка появится во всех приложениях компании. В таких командах снепшот-тесты реально приносят пользу и экономят деньги.
Но я вижу тенденцию, что эти тесты пытаются затащить в само приложение. Ведь они так просто внедряются, всего пара аннотаций на Compose функцию. По мне, так в приложении в снепшотах столько же смысла, как в сюжете порно. Они очень хрупкие, дорогие в поддержке, и непонятно, какая от них реальная польза.
Что такого вы можете сделать в коде, от чего вас спасут эти тесты? Я просто не понимаю, как можно накосячить в верстке так, чтобы всё сломалось. Compose позволяет даже сложные экраны верстать в полмозга, левой пяткой. В верстке нет сложной логики, которую мы можем сломать изменениями. Или вы падинги рассчитываете по сложной формуле?
Я понимаю, можно накосячить со сложными анимациями, но анимации снепшотами не протестируешь – вообще никак не протестируешь.
Команды, которые внедрили себе снепшот тесты, постоянно страдают. Недавно показывают две идентичные картинки, в которых автоматика находит пару отличающихся пикселей. Причина в том, что эталон снимался на устройстве с одним разрешением, а на ферме эмуляторов сейчас другое. И теперь нужно перелопатить все тесты, чтобы это починить. Бессмысленная дрочь….
Может, у вас есть истории успеха, где такие тесты реально спасли релиз?
BY Dev Easy Notes
Share with your friend now:
tgoop.com/dev_easy_notes/395