Телеграмм чат группы qa_automation страница 7033

И не только непрозрачность, но и все остальные проблемы программирования

13:01пожаловаться #1

Я не это имею в виду.

Любую аннотацию можно имплементировать кодом без аннотаций. Ну и очевидно покрытие этого кода легко подсчитать. А аннотация третей библиотеки прячет этот код.

13:01пожаловаться #2

Alexander Push in QA — Automation

ну хз, насчет всем. в моей тусовке никому не нравится, нас конечно мало, но мы в тельняшках

13:01пожаловаться #3

Alexander Push in QA — Automation

я думаю мы с Алескеем он зе сейм пейдж тут

13:02пожаловаться #4

> Любую аннотацию можно имплементировать кодом без аннотаций
Звучит как “Давайте все откажемся от спринга, ведь Алексей не может пользоваться техниками тест-дизайна”

13:04пожаловаться #5

Ну тут я не утверждаю, что аннотации плохо, но хорошо понимать эти особенности.

Отлично, когда код не надо тестировать по другому, из-за аннотаций - значит аннотации простые, надёжные, прямолинейные, без неожиданный сайд эффектов.
Типа @Role выглядит как такая простая прямолинейная аннотация.

13:05пожаловаться #6

Я первый начал переходить на личности, поэтому этот раз пропустим - в следующий раз за такие "Алексей не умеет" тебя ждёт РО или бан

13:07пожаловаться #7

Anton Khayrutdinov in QA — Automation

Я сам не сторонник проверять роли аннотациями (не смотря на то, что неоднократно так делал), но по иной причине. Покрытие кода не позволяет находить определенные классы ошибок, в этом я с Дмитрием согласен. Впрочем, я весь диалог не читал, так что возможно спор от другом). Но аннотации это просто инструмент, ничего в них зашкварного нет.

13:07пожаловаться #8

Нигде и не написано что зашкварный

13:08пожаловаться #9

Alexander Push in QA — Automation

ваш выпад в сторону Алексея, как минимум, некорректен) есть объективная зависимость между использованием фреймворков и аннотаций с усложнением и ростом затрат на тестирования. Тактики тест дизайна не решают проблему, а лишь "смазывают" ее. Рекомендую ознакомиться с докладами и работами Игоря Хролла, Uncle Bob Martin, Андрея Солнцева, Меня любимого, Егора Бугаенко и J.B. Rainsberger.

13:08пожаловаться #10

Alexander Push in QA — Automation

зашквартный

13:08пожаловаться #11

Алексей уже признал, что первый начал.
Эх, сейчас бы на бугаенко и себя любимого ссылаться…

13:09пожаловаться #12

Alexander Push in QA — Automation

ну мне не стыдно, я понаписал всяких работ (а Бугаенко понаписал кучу реально инновационных научных исследований, о чем не знать - стыдно)

13:10пожаловаться #13

Давайте не будем искать кто где хуже знает, приводите аргументы по существу, тогда будет диалог. А за постоянные выходы на личности будет бан, так просто всё.

13:11пожаловаться #14

Таких исследований, что его в мемах изображают и на всех конференциях забанили

13:11пожаловаться #15

Его банят за другое, и опять же не личность обсуждайте тут, а конкретные тезисы

13:11пожаловаться #16

Alexander Push in QA — Automation

Леша, ну тут сложно аргумент. Могу скинуть докладик на дцать страниц на английском.

13:12пожаловаться #17

Alexander Push in QA — Automation

Проще говоря - аннотации добавляют accidental complexity и скрывают код, который вызывается. В результате чего логика, которую можно было бы проверить unit тестом приходится проверять тестом системного уровня

13:12пожаловаться #18

Alexander Push in QA — Automation

тесты системного уровня по умолчанию дороже и сложнее, и техники тест дизайна работают слабо, т.к. они исходит из заведомо невозможного покрытия всех состояний и ветвлений системы.

13:13пожаловаться #19

Alexander Push in QA — Automation

аннотации и фреймворки значительно усложняют саму систему и делают ее менее прозрачной.