Ш
связь только с одним элементом, а не со множеством/списком
Size: a a a
2021 May 12
Ш
и он обязателен
2021 May 15
AZ
Подача vertical slices + onion arch под какой-то новой обёрткой с модным словом "контейнер" 🤦♂ https://github.com/Mahmoudz/Porto
BT
*открыл*
The Ship layer, contains the Parent "Base" classes (classes extended by every single component) and some Utility Code.
*закрыл*
The Ship layer, contains the Parent "Base" classes (classes extended by every single component) and some Utility Code.
*закрыл*
BT
чувак просто решил сделать велосипед, бывает
DW
А чем плоха эта работа? 🙂 Ну да в ней есть что-то от vertical slices только теперь это контейнеры), но в ней достаточно подробно и предметно описано как,куда и зачем.
AZ
> Porto inherits concepts from the DDD (Domain Driven Design), Modular, Micro Kernel, MVC (Model View Controller), Layered and ADR (Action Domain Responder) architectures.
Работа идеальна, квинтесенция лучших практик, надо брать
DDD + Micro kernel + modular + mvc + adr + SOLID + OOP + LIFT + DRY + CoC + GRASP + Generalization + High Cohesion and Low Coupling = PROTOРабота идеальна, квинтесенция лучших практик, надо брать
DW
))
2021 May 16
КГ
А разве технически юнит тесты не блэкбокс?
Мы же всегда тестируем апи, разница только в размере бокса, от апи функции до апи всего проекта
Мы же всегда тестируем апи, разница только в размере бокса, от апи функции до апи всего проекта
AM
Если юнит-тесты пишет разработчик кода и не следуют TDD, то это сложно блекбоксом назвать.
КГ
Я к тому, что блэкбокс или нет зависит от реализации теста, а не юнит он или не юнит.
А что без tdd невозможно блэкбокс тест написать?)
А что без tdd невозможно блэкбокс тест написать?)
SZ
это отсылка к вечному срачу - нам е2е хватит или нужно покрывать каждую функцию отдельно
AM
Ну да, согласен.
Возможно. А вот без test-first подхода разве что в том случае, если тест пишет человек, который ни разу не смотрел тестируемый кусок кода
Возможно. А вот без test-first подхода разве что в том случае, если тест пишет человек, который ни разу не смотрел тестируемый кусок кода
КГ
Что-то не догоняю. Ну вот я знаю что внутри, но так же знаю как клиенты должны использовать апи.
Что мне помешает написать тест используя типичные кейсы клиента, при этом не упарываясь в нюансы реализации?
Что мне помешает написать тест используя типичные кейсы клиента, при этом не упарываясь в нюансы реализации?
AM
Ключевым в подходе как раз и является то, что тестер не должен знать о реализации, т.к. даже не имея желания делать тест, завящий от конкретной реализации, может сделать это чисто случайно.
DT
Можно, но это изначально предвзятый взгляд. Т.е. реализация диктует какими будут тесты, а не наоборот. Это идеологически неверно, когда требования определяются реализацией, но это ж не догма
SP
если у тебя инженеры и без юнит тестов internal quality могут обеспечить, если у тебя "модули" там и ты знаешь как уменьшить влияние зависимостей на вариативность тестов, то да тебе может хватить e2e.
SP
а когда у тебя разработчики делают в тестах там датапровайдеры какие или циклы где "надо проверить для каждой роли и проверить все пермутации бездумно" - то нет, e2e покроет только малую часть возможных ситуаций. Потому что факториал