VB
я спрашиваю практики, которые тут используются
Size: a a a
2020 February 05
VB
мне не надо пояснять что из этого что
VB
объективная оценка что из этого лучше для фронтового ангуляра, вот чего я спрашиваю
П
Да пофиг на фреймворк
Юнит тест самый дешевый способ
Юнит тест самый дешевый способ
П
Потом можно накручивать
VB
дешёвый способ чего? слить время вникуда на тестирование компонента фронта? спасибо в общем за ответ в любом случае, но вопрос всё ещё остаётся открытым
П
ну если ты так считаешь, то можешь вообще не тестировать
Д
если не тестировать в продакшене найдутся все баги. Если тестировать в продакшене найдутся самые интересные
IF
e2e имхо самый эффективный тест, но в случае, когда бэк тоже тестируется
IF
То бишь бд наполняется фейком, и код и бэка и фронта проверяется
П
и самый сложный для поддержки
IF
Ну юниты часто так готовятся, что бестолковые выходят
VB
e2e имхо самый эффективный тест, но в случае, когда бэк тоже тестируется
вот я сейчас на нём почти остановился, протрактор используете?
E
1. Пирамиду тестирования (юнитов больше всего, е2е меньше всего) пока никто не отменял и она достаточно обоснована.
2. В каждой компании есть свои ограничения (ресурсы, знания, архитектура), так что все выкручиваются кто как может, одного рецепта нет, к сожалению(
2. В каждой компании есть свои ограничения (ресурсы, знания, архитектура), так что все выкручиваются кто как может, одного рецепта нет, к сожалению(
VB
1. Пирамиду тестирования (юнитов больше всего, е2е меньше всего) пока никто не отменял и она достаточно обоснована.
2. В каждой компании есть свои ограничения (ресурсы, знания, архитектура), так что все выкручиваются кто как может, одного рецепта нет, к сожалению(
2. В каждой компании есть свои ограничения (ресурсы, знания, архитектура), так что все выкручиваются кто как может, одного рецепта нет, к сожалению(
Согласен с пирамидой для систем в которых есть бизнеслогики достаточно, но вот не совсем согласен с её применением на фронте
IF
Для себя полезнее юниты писать - тогда разговоры про правильное ООП становятся актуальными)
EG
Ну юниты часто так готовятся, что бестолковые выходят
От юнитов много пользы, если вы логику выносите из компонента в сервис/стор, отделяя её от представления. Юниты для компонентов могут быть полезны разве что вы свой ui-кит с нуля пишите
E
Согласен с пирамидой для систем в которых есть бизнеслогики достаточно, но вот не совсем согласен с её применением на фронте
Она же не только про логику, даже не столько. Она больше про скорость и устойчивость. е2е тесты самые нестабильные, самые сложные в поддержке и т.д.
VB
От юнитов много пользы, если вы логику выносите из компонента в сервис/стор, отделяя её от представления. Юниты для компонентов могут быть полезны разве что вы свой ui-кит с нуля пишите
с этим согласен, звучит логично, тут уже скорее сказывается специфика проекта, в котором бизнеслогика вынесена практически вся на бек
П
ну у нас например сотни юнит тестов в одном и более 1.5 тысячи в другом. они ни разу не бесполезные