AP
это дает сильно больше уверенности что все ок, и не писать огромное количество тестов на каждом из уровней ниже сервисов
Size: a a a
2020 March 03
AK
в них не написано что они unit) на уровне сервисов у меня тесты работающие с базой, а у же уровнем выше чистые юнит тесты без реального вызова сервисов
Т.е. ты по сути тестируешь репозитории?) ну querybuilder :) зачем это?
AP
1) там тоже есть код 2) тестируются и миграции 3) тестируется консистентность в базе и что она соблюдается, то есть что у меня связанные изменения в базе проходят в рамках одной транзакции а не разных 4) протестировать все вышеперечисленное проще на этом уровне чем выше, так как выше уже сложно быстро понять суть проблемы
AK
1) там тоже есть код 2) тестируются и миграции 3) тестируется консистентность в базе и что она соблюдается, то есть что у меня связанные изменения в базе проходят в рамках одной транзакции а не разных 4) протестировать все вышеперечисленное проще на этом уровне чем выше, так как выше уже сложно быстро понять суть проблемы
Выше я говорил про юнит тесты, а не про интеграционные. Не думаю что в юнит тестах есть смысл такое делать
AP
согласен, я в целом не навязываю, просто практика зарекомендовала себя с хорошей стороны на нескольких проектах, так что я просто поделиться)
AP
@alexkazantsev дочитал до оригинального вопроса, конечно ты прав реальных вывозов внешних сервисов кончено нужно избегать на этом этапе тестирования
AM
W
Ребят, подскажите хорошую струтуру папок проекта. Как лучше расскладывать. Из докуи понял что Гардс и прч в папке коммон должно быть
MY
Ребят, подскажите хорошую струтуру папок проекта. Как лучше расскладывать. Из докуи понял что Гардс и прч в папке коммон должно быть
ну так можно сделать папки
guards, interceptors, ...MY
а создавать папки типа
common, core - так лучше не делатьIK
Если на несколько проектов один common то он уже core
LK
Ребят, подскажите хорошую струтуру папок проекта. Как лучше расскладывать. Из докуи понял что Гардс и прч в папке коммон должно быть
сначала делай как удобно, как в доке неста может видел
потом когда поймешь что можно сделать лучше тогда уже переделаешь
а имплемеентить чьи то советы без понимания зачем так сделали бессмысленно
ну и делать так как другие тоже плохо, у каждого свой путь )
потом когда поймешь что можно сделать лучше тогда уже переделаешь
а имплемеентить чьи то советы без понимания зачем так сделали бессмысленно
ну и делать так как другие тоже плохо, у каждого свой путь )
MY
сначала делай как удобно, как в доке неста может видел
потом когда поймешь что можно сделать лучше тогда уже переделаешь
а имплемеентить чьи то советы без понимания зачем так сделали бессмысленно
ну и делать так как другие тоже плохо, у каждого свой путь )
потом когда поймешь что можно сделать лучше тогда уже переделаешь
а имплемеентить чьи то советы без понимания зачем так сделали бессмысленно
ну и делать так как другие тоже плохо, у каждого свой путь )
наверное, самый лучший вариант
AM
Ребят, подскажите хорошую струтуру папок проекта. Как лучше расскладывать. Из докуи понял что Гардс и прч в папке коммон должно быть
У нас довольно неплохо лёг angular style guide
W
Ребят, спасибо за советы!
W
У нас довольно неплохо лёг angular style guide
чекну, спасиб
AM
Правда, в нём не сказано куда положить бизнес-логику :)
W
Правда, в нём не сказано куда положить бизнес-логику :)
))))))
MY
Правда, в нём не сказано куда положить бизнес-логику :)
AM
Ну это наверное логично, как и нест — ангуляр это фреймворк. Всё равно придётся думать как удобнее конкретно тебе. Но сущности неста неплохо раскладываются.