C
чистую архитектуру начинаешь прям любить, когда дело доходит до юнит-тестов
а какие проблемы есть с юнит тестами на грязной архитектуре?
Size: a a a
2020 February 24
AK
https://medium.com/@manakuro/clean-architecture-with-go-bce409427d31 еще по тем немного.
DP
а какие проблемы есть с юнит тестами на грязной архитектуре?
или у тебя юниты превращаются в интеграционные, или ты пишешь очень сложные моки
C
а какие проблемы есть с юнит тестами на грязной архитектуре?
нетестируемый код
ЛА
нетестируемый код
Разве сложность тестирования не определяется в основном зависимостями от сложных сервисов?
А так разбить код на фции имхо можно при любой архитектуре.
А так разбить код на фции имхо можно при любой архитектуре.
C
или у тебя юниты превращаются в интеграционные, или ты пишешь очень сложные моки
тогда в чем разница между моками в clean arch и не clean arch?
C
Разве сложность тестирования не определяется в основном зависимостями от сложных сервисов?
А так разбить код на фции имхо можно при любой архитектуре.
А так разбить код на фции имхо можно при любой архитектуре.
мы сейчас говорим про две крайности — стремление к чистой архитектуре и грязная :)
C
и никто, заметьте, никто не говорит, что надо к этому бежать бросая всё
C
не додумывайте
SP
а какие проблемы есть с юнит тестами на грязной архитектуре?
с юнит кажись никаких а когда блин нет интерфесов - то нельзя мокать в интеграционных и это ппц
C
с юнит кажись никаких а когда блин нет интерфесов - то нельзя мокать в интеграционных и это ппц
согласен
DP
тогда в чем разница между моками в clean arch и не clean arch?
чем чище архитектура - тем проще мок
C
чем чище архитектура - тем проще мок
😄не поспоришь
АП
ат сорян, не так прочитал
DP
это довольно частый вопрос - мокать ли базу данных
и ответов на него примерно два:
1. не мокать, написать интеграционные тесты
2. не мокать, написать DAL и мокать его
польза от чистой архитектуры в том, что, если ее принципы соблюдать - DAL получится сам, и вопрос о моках базы просто не возникнет
и ответов на него примерно два:
1. не мокать, написать интеграционные тесты
2. не мокать, написать DAL и мокать его
польза от чистой архитектуры в том, что, если ее принципы соблюдать - DAL получится сам, и вопрос о моках базы просто не возникнет
DP
кто мне тут инфлюкс хвалил?
я вот смотрю на https://github.com/influxdata/influxdb/issues/16901
последний стабильный просто поломан. вот реально - просто поломан
я вот смотрю на https://github.com/influxdata/influxdb/issues/16901
последний стабильный просто поломан. вот реально - просто поломан
C
это довольно частый вопрос - мокать ли базу данных
и ответов на него примерно два:
1. не мокать, написать интеграционные тесты
2. не мокать, написать DAL и мокать его
польза от чистой архитектуры в том, что, если ее принципы соблюдать - DAL получится сам, и вопрос о моках базы просто не возникнет
и ответов на него примерно два:
1. не мокать, написать интеграционные тесты
2. не мокать, написать DAL и мокать его
польза от чистой архитектуры в том, что, если ее принципы соблюдать - DAL получится сам, и вопрос о моках базы просто не возникнет
DAL это типо интерфейс абстрагирующий нас от стора?
DP
DAL это типо интерфейс абстрагирующий нас от стора?
типа да
SP
это довольно частый вопрос - мокать ли базу данных
и ответов на него примерно два:
1. не мокать, написать интеграционные тесты
2. не мокать, написать DAL и мокать его
польза от чистой архитектуры в том, что, если ее принципы соблюдать - DAL получится сам, и вопрос о моках базы просто не возникнет
и ответов на него примерно два:
1. не мокать, написать интеграционные тесты
2. не мокать, написать DAL и мокать его
польза от чистой архитектуры в том, что, если ее принципы соблюдать - DAL получится сам, и вопрос о моках базы просто не возникнет
Я пищу тесты интеграционные сперва на методы для БД а потом мокаю их мкокойно в других функциях где мне надо