Научить бы ещё эту либу запускаться только для строк покрытых тестами. Т.о. получится метрика качества именно тестов, а не проекта в целом. Для случаев с небольшим, но растущим покрытием было бы супер-удобно.
Отец занимался ремонтом телевизоров. Я был в средних классах школы. Он ковырял очередной телек. Только отключил его и снял «лягушку» с кинескопа (эт такой круглый резиновый изолятор вокруг кабеля, который снимает высокое напряжение с кинескопа). Вот туда я и сунул палец — в ответную часть на кинескопе. Фиг знает сколько там, но я на автопилоте сделал шаг-другой назад и присел попой на диван.
Он так много автоматизировал по началу, что я уж было подумал, что в конце окажется будто собеседник — робот, и все в компании роботы, и вообще этот программер последний кто остался из живых.
Я себе такой велосипед изобретал против параллельного обновления кэша: обернул методы set/get кэша, добавил внутри сеттера в сам кэш данные о ttl и датах создания-протухания, а потом в геттере проверял, сколько кэш уже живёт в момент обращения к нему. Если прожил 90% от своего срока, то продлевал ему время жизни ещё немного, но наружу всё равно возвращал false. В итоге код, запрашивающий данные, получал false и шёл обновлять их думая что их нет, но все прочие клиенты получали старые данные следующие пару секунд.
Да, надо знать наизусть, если хочешь получить сертификат ZCE. Да, надо знать, что это и как этим пользоваться, если хочешь пройти собеседование с HR в том же Badoo и добраться до собеседования с технарями (из личного печального опыта, в поддержку #меняневзяли).
Соглашусь, что это лишнее и пользы на первых порах — ноль. Но если уж взялся, то доведи дел до конца. А то какие-то полумеры получаются. Тем более что задачу из темы статьи в итоге статья не решает. Только как ликбез для начинающих.
Я не сторонник этого подхода для автотестов: простота написания таких тестов иллюзорна.
Но всё равно выбрали такое решение? Неужели профит на столько высокий? Во что выливаются изменения экранов и дерева элементов на них? А изменение flow различных процессов в приложении? Чем не устроил какой-нибудь WDA от Facebook'а в купе с кастомными PageObject'ами?
Научить бы ещё эту либу запускаться только для строк покрытых тестами. Т.о. получится метрика качества именно тестов, а не проекта в целом. Для случаев с небольшим, но растущим покрытием было бы супер-удобно.
Не стоит открывать демку на слабой машине)
habrahabr.ru/company/piter/blog/323310
Один в один.
Соглашусь, что это лишнее и пользы на первых порах — ноль. Но если уж взялся, то доведи дел до конца. А то какие-то полумеры получаются. Тем более что задачу из темы статьи в итоге статья не решает. Только как ликбез для начинающих.
Но этой ссылки нет даже в списке доп.литературы.
Но всё равно выбрали такое решение? Неужели профит на столько высокий? Во что выливаются изменения экранов и дерева элементов на них? А изменение flow различных процессов в приложении? Чем не устроил какой-нибудь WDA от Facebook'а в купе с кастомными PageObject'ами?