Привет всем! Есть знатоки gitlab CI? Не могу понять, почему при следующем конфиге не создается install_dependencies job, когда у нас непосредственно поменялся .gitlab-ci.yml файл? Может я что-то упускаю?

stages:
 - install_dependencies
 - test

.cache-template: &cache-template
 cache:
   key: $CI_COMMIT_REF_SLUG-$CI_PROJECT_DIR
   paths:
     - node_modules/
   policy: pull

install_dependencies:
 stage: install_dependencies
 cache:
   paths:
     - node_modules/
   key: $CI_COMMIT_REF_SLUG-$CI_PROJECT_DIR
   policy: push
 script:
   - npm ci
 only:
   changes:
     - package-lock.json
     - .gitlab-ci.yml

lint:
 <<: *cache-template
 stage: test
 script:
   - npm run lint
 rules:
   - when: always

tests:
 <<: *cache-template
 stage: test
 script:
   - npm test
 rules:
   - <<: *if-release-branch
   - <<: *if-release-tag
     when: never
   - when: always
 retry: 1

У вас их две почему-то

Один stage, другой job... Вроде тут чисто

А, то телеграм с телефона перенос сделал

Всем привет.

Впервые покрываю компонент тестами, возникла, наверное, распространенная проблема с правильным определением конечного числа сценариев, которые нужно тестами покрыть.  Ведь нет смысла покрывать все подряд, ибо иногда это трата времени, не приносящая особой выгоды.

К слову, компонент -> 3х шаговая формочка. В зависимости от activeStep отображается один из трех экранов, проходя каждый из которых юзер уходит вглубь.

С моей, джуновской т.з., выделил следующие сценарии, которые надо покрывать в данном кейсе:

- describe на переход на второй экран с первого (проверить, что он должен осуществиться только тогда, когда все поля    провалидированы и запрос на бэк зарезолвился). Данный сценарий разбивается на следующие 'it':
 1) показ ошибки у каждого поля, если оно не прошло валидацию,
 2) проверка самой валидации на разных данных (тут уже сложно, ибо кейсов может быть много),
 3) проверка успешного асинхронного запроса - activeStep должен стать +1,
 4) проверка зафейлившегося асинхронный запроса -> должна отобразится ошибка

- describe для экрана 2:
 - describe на корректную работу логики "выслать код"

 - тесткейс на кнопку "назад" (activeStep должен стать минус 1)

 - describe на переход с 2 шага на 3й:
   1) тесткейс на валидацию,
   2) тесткейс на показ ошибки при непрохождении валидации,
   3) тесткейс на успешный асинхронный запрос,
   4) тесткейс на фейл асинхронного запроса


Подскажите, пожалуйста, не дергается ли глаз от такого "покрытия", похоже ли это на что-то около "нормальное" ?

Зависит от целей и покрыты ли нижние компоненты тестами и если да то тестами каких уровней

если по самой диаграмме то она немного кривовата

Привет всем) кто-нибудь знает как в ангуляр 9 либе исключить json файл с папки assets в корне (не в src/assets) ? angular.json ... architect.build.options не принимает assets для либ 😟

а зачем тестировать валидацию на разных данных?
валидаторы надо отдельно тестировать
а в этой форме просто убедиться что 100% проверенный валидатор запустился и вернул ОК

или даже что валидатор просто запустился в принципе
на случай если кто-то потом его выпилит по какой то причине из формы

тоже самое с проверкой асинхронного запроса

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

важен сам факт вызова

а тестирование самого запроса в разных позах с разными параметрами это в другом месте уже

Цель - ну, наверное, как обычно - автоматизировать проверку существующей логики этого компонента, чтобы при изменениях не прогонять ручные тесты

Нижних компонентов по сути нет, данный компонент как отдельный замкнутый виджет, который отображается на странице один без связи с другими элементами

(если я правильно понял понятие "нижних компонентов")

Имеется в виду, что отдельно проверяется запустился ли вообще сам сайд эффект, а в другом блоке уже логика того, как компонент реагирует на его ответы, так ?

это к вопросу Ильи про нижние компоненты

у тебя есть валидаторы, есть запросы

опять же вопрос как сделаны инпуты с валидаторами
это отдельные компоненты или это нативные хтмл инпуты, а валидаторы в виде внутренней функции компонента формы