Size: a a a

Software Design/Architecture/Zen

2021 May 24

DE

Dmitry Eliseev in Software Design/Architecture/Zen
Вот в E2E да, нужны отдельные эндпоинты. Тогда можно будет такие тесты запускать хоть в https://cypress.io
источник

EE

Evgenii Evgenivich in Software Design/Architecture/Zen
Write/Read Model тема.
Можно делать отдельные ридмодели и обновлять их на основе событий.
Можно джобу делать которая селектить и строит ридмодели.
источник

DE

Dmitry Eliseev in Software Design/Architecture/Zen
В таком случае сделать так, чтобы не нужно было передавать эту же ентитю.
источник

AD

Apache DOG™ in Software Design/Architecture/Zen
Автогенеренные кодеки
источник

ST

Serguei Tarassov in Software Design/Architecture/Zen
для дебилов :) уточняю: "белый" ящик позволяет сократить число тестов на соответствующем уровне реализации. Пример "для гуманитариев"с перегрузкой функций  - выше.
источник

SP

Sergey Protko in Software Design/Architecture/Zen
изоляция и контракты.
источник

V

Viktor in Software Design/Architecture/Zen
Можно ли из энтити тогда возвращать дтошки
Или лучше все-таки будет еще раз сходить в репозиторий и взять дтошки
источник

SP

Sergey Protko in Software Design/Architecture/Zen
ящики у них там белые
источник

SP

Sergey Protko in Software Design/Architecture/Zen
хватит людям некорректные метафоры предлагать
источник

EE

Evgenii Evgenivich in Software Design/Architecture/Zen
А можно маппер из ентити в дто, при учете что свойства энтити на гет есть
источник

SP

Sergey Protko in Software Design/Architecture/Zen
если у тебя два публичных метода и один публичный метод дергает другой - для тебя это основание что бы не тестить и тот и другой? И в этом смысл "белости ящика"? С какого перепугу в твоем примере меньше тест кейсов
источник

V

Viktor in Software Design/Architecture/Zen
Вот к этому я в прошлый раз пришел, но не захотел лишние геттеры делать вообще
источник

EE

Evgenii Evgenivich in Software Design/Architecture/Zen
Ну делать метод у сущности Entity.ToDTO() тож не каеф
источник

EE

Evgenii Evgenivich in Software Design/Architecture/Zen
Тогда делать рид модель на основе событий произошедших в домене и персистить их перед комитом.
источник

SP

Sergey Protko in Software Design/Architecture/Zen
тут либо "белый ящик не белый потому что он все еще ящик и мы его тестим, не важно с "реальными" или фэйковыми зависимостями либо "белый ящик это хуевые тесты которые дублируют реализацию и являются антипаттерном" тебе выбирать
источник

SP

Sergey Protko in Software Design/Architecture/Zen
уменьшение количества тесткейсов происходит за счет изоляции этих тест кейсов, с целью уменьшить пермутации. Тут важн очто бы границы были, и только
источник

V

Viktor in Software Design/Architecture/Zen
Согласен. Но однозначно "хорошего" так и не нашел
источник

EE

Evgenii Evgenivich in Software Design/Architecture/Zen
Ну я вижу свободу в ридмоделях на основе событий.
источник

EE

Evgenii Evgenivich in Software Design/Architecture/Zen
Это реально свобода
источник

SP

Sergey Protko in Software Design/Architecture/Zen
я вижу "нюансы" в ситуациях когда порядок ивентов нарушается либо надо выводить это дело в бэкграунд с outbox.

это оч мощная штука но возможно слишком сложно для кейсов когда "делать в пределаз запроса (раз у тебя там общий коммит транзакции) вместо просто вьюшки"
источник