OK
это будет намного дешевле и эфективней. Мониторить автотестом очень ненадежно
Size: a a a
2021 September 08
ЧА
Я так понял что есть health check на кубернетес, но он не помогает выявить проблему так как сервис формально работает и возвращает 200. С логами да, согласен
AV
Ну это понятно.
Если абстрагироваться от авторизации и спрингов - то метод который тестируем примерно такой:
boolean canIdoIt(Role role)
If (role=abc) return true else return false.
И тут как бы очевидно, что больше двух тестов это чудачество.
Если абстрагироваться от авторизации и спрингов - то метод который тестируем примерно такой:
boolean canIdoIt(Role role)
If (role=abc) return true else return false.
И тут как бы очевидно, что больше двух тестов это чудачество.
AV
Если на той код считаете разумным написать 50 тестов, то окей в принципе, кто я такой чтобы возражать.
AV
Проще всего сделать так, напишите сейчас 50 тестов. В следующий раз на аналогичный код 2. Через 3-6 месяцев сравните, что получилось. Лучше всего ошибки понимаются, когда сам их совершил, из чужих уст всегда звучит неубедительно.
LY
Нужно смотреть реализацию, и разговаривать с разработчиками.
Как правило, контроль доступа имеет весьма запутанную логику, и не сводится к примитивному if'у. Роли, группы, под-группы и исключения.
Если в этом разбираться нет времени/ресурса - проще написать 50 тестов.
Если есть - напишите тот минимум который покроет большинство случаев.
Как правило, контроль доступа имеет весьма запутанную логику, и не сводится к примитивному if'у. Роли, группы, под-группы и исключения.
Если в этом разбираться нет времени/ресурса - проще написать 50 тестов.
Если есть - напишите тот минимум который покроет большинство случаев.
AV
Покрытие помогает обнаружить забытые кейсы на поведение, а избыточное покрытие - лишние тесты. например если мы неправильно классы эквивалентности определили и разбили на слишком много.
Ну и конечно - лишний и/или неправильный код самого приложения.
Вот как покрытие применяют вместе с тестами на поведение, не более и не менее.
Ну и конечно - лишний и/или неправильный код самого приложения.
Вот как покрытие применяют вместе с тестами на поведение, не более и не менее.
AV
Если у авторизации не просто @Role("abc") над методом, а какая-то логика - то и классы эквивалентности конечно появятся новые. Но часто это просто одна анноташка, которая суть простой if.
AK
ВСЕХ С ДНЕМ ИЗВИНЕНИЙ
D
> Покрытие помогает обнаружить забытые кейсы на поведение
Покрытие это вспомогательная метрика и никак не отменяет необходимость в тест-дизайне на основе бизнес требований
> Но часто это просто одна анноташка, которая суть простой if.
Как покрытие кода поможет определить, что ты забыл добавить аннотацию на 1 роль из 50?
Покрытие это вспомогательная метрика и никак не отменяет необходимость в тест-дизайне на основе бизнес требований
> Но часто это просто одна анноташка, которая суть простой if.
Как покрытие кода поможет определить, что ты забыл добавить аннотацию на 1 роль из 50?
PN
Ребят у кого есть Ui тесты Selenium на Java которые в Docker контейнере запускаются.Дайте ссылку на Git нужно посмотреть как конфиг правильно прописывать.Второй день мучаюсь с Dockerfile +Compose +Runner для RemoteDriver
АЧ
Thank you so much)
MS
и со мной пожалуйста поделитесь аналогичной информацией
AV
В этом проблема аннотаций, конечно. Они выглядят красиво, но затрудняют определение покрытия, есть такой факт.
Если бы своя кастомная аннотация - то в ней покрытие тоже измеряем, разумеется.
Если бы своя кастомная аннотация - то в ней покрытие тоже измеряем, разумеется.
D
> Как покрытие кода поможет определить, что ты забыл добавить аннотацию на 1 роль из 50?
AP
никак. отчасти поэтому прогрессивное разработчество ненавидит аннотации люто и бешено.
AP
🥰
AK
А это точно проблема аннотаций? А если в код контроллера ты забыл добавить проверку роли пользователя, тебя как-то спасет 100% покрытие?
D
Это был мой следующий вопрос Алексею)
D
Всем нравятся. Непрозрачность аннотаций решается хорошим покрытием по требованиям с правильным тест-дизайном