AB
но при этом было разделение труда, тесты писал не тот человек, который разрабатывал тестируемый код. так тоже бывает :)
Size: a a a
2019 November 14
EB
так это не вопрос измерения покрытия, вам сигнал о написании новых тестов стал бы гит и дифф комитов с явно новой логикой
EB
для этого даже не нужно знать, что там покрыто было и на сколько было покрыто раньше
AB
и что, вручную все диффы анализировать и угадывать, нет ли там кода, который тестами не покрывается?
AB
лично я так не умею :)
EV
Ну тогда понятно. Без покрытия не прожить.
Случай тоже из практики. Когда в системе несколько бекендов, и один стек весь покрывается юнитами, а второй кладезь непокрытого кода. А поскольку они тесно взаимодействуют между собой, то блек-бокс юайщикам принято считать, что не покрыто ничего юнитами, надежда только на мануал и юайные автотесты🙈
Случай тоже из практики. Когда в системе несколько бекендов, и один стек весь покрывается юнитами, а второй кладезь непокрытого кода. А поскольку они тесно взаимодействуют между собой, то блек-бокс юайщикам принято считать, что не покрыто ничего юнитами, надежда только на мануал и юайные автотесты🙈
S
Выглядит как костыль, вместо того чтобы организовать написание тестов разработчиками кода. Но задачу конечно решает.
EB
ну например у тебя сортировка которая решает на малой коллекции за N log n, а другая на больших колекциях написано по-другому, и у тебя там в твоей процедуре стоит тоггл: если размер коллекции такой, делай так, а если больше, то делай вот так
EB
неужели увидев изменение в коде не возникнет ощущения, на каком тестовом массиве данных проверить изменение в условиях вайт-бокса? =)
ZE
Ну тогда понятно. Без покрытия не прожить.
Случай тоже из практики. Когда в системе несколько бекендов, и один стек весь покрывается юнитами, а второй кладезь непокрытого кода. А поскольку они тесно взаимодействуют между собой, то блек-бокс юайщикам принято считать, что не покрыто ничего юнитами, надежда только на мануал и юайные автотесты🙈
Случай тоже из практики. Когда в системе несколько бекендов, и один стек весь покрывается юнитами, а второй кладезь непокрытого кода. А поскольку они тесно взаимодействуют между собой, то блек-бокс юайщикам принято считать, что не покрыто ничего юнитами, надежда только на мануал и юайные автотесты🙈
Вполне прожить, покрытие кода, в большей части случаев, не твоя проблема
LY
Да, покрытие для юнитов
ZE
Смаппи свои тастики на требования и спи спокойно. Если разрабы не предупредили и тестов на это не было, то тут уж наши полномочия все
EV
Если пишешь юни тесты, разве покрытие не проблема того, кто их пишет?
Выше говорилось о юнитах кажется
Выше говорилось о юнитах кажется
EV
Которые пишутся другим человеком
AB
неужели увидев изменение в коде не возникнет ощущения, на каком тестовом массиве данных проверить изменение в условиях вайт-бокса? =)
иногда, конечно, это очевидно, что надо добавить тестов, но не всегда. я не умею вручную эффективно анализировать диффы с такой целью. да и зачем, если можно просто измерить покрытие
ZE
Если пишешь юни тесты, разве покрытие не проблема того, кто их пишет?
Выше говорилось о юнитах кажется
Выше говорилось о юнитах кажется
Если автоматер пишет юниты причиняющие пользу, то он хорошо погружен в проект и стэк. Он или будет дорогим или уйдет в погромисты
PK
можно через ActionChains, только кликать на определенные координаты ( забирать координаты и размер объекта, вычислчть видимую область и кликать в центр)
Это не помогло, я писал выше, что использовал
Actions. И повторю, что не кликать нужно, а файл отправить ( sendKeys )PK
так гляньте что за элемент перекрывает для начала, может там прозрачный оверлей какой то...
разве это что-то изменит?
OK
разве это что-то изменит?
Ну может у вас там сообщение об ошибке с прозрачным оверлеем вылетело
PK
Ну может у вас там сообщение об ошибке с прозрачным оверлеем вылетело
нет, такого там нету. Никаких алертов, месседжей, ничего