В среднем 3-4 теста на компонент. Картинок в одном тесте порядка двух-трёх десятков. Например, у нас самый богатый на свойства компонент это Button. У него общее количество сгенерированных картинок - 120, тестов - 6, в одной пачке примерно 20 картинок.
насколько просто искать место которое нужно править.
А названия отдельных тестов и их структура тут мало решают на самом деле при починке. Проще сразу пробежаться глазами по диффу картинок. По нему сходу более-менее всё понятно.
На практике это обычно выглядит так:
На CI неожиданно упали snapshot-тесты.
Прогоняем локально с включенным record: true. Фреймворк перезаписывает изменившееся.
Смотрим по гиту изменившиеся картинки. Тот же Fork (гит клиент), например, удобен тем, что умеет diff картинок делать разными способами. Можно любые сдвиги до пикселей разглядеть. Тут уже обычно понятно, что сломалось в 99% случаев. Ниже приложил пару скринов из Fork'а.
Если изменения логичные и оправданные - просто коммитим вновь сгенерированные картинки.
Если неоправданные и что-то сломалось - идем править.
Если непонятно какие изменения в коде сломали тесты - полезно опять же гитом сделать diff кода от последнего стабильного состояния для папки с кодом компонента - тут ловится еще 1% сложных случаев.
Если все равно непонятно - тогда это уже совсем тяжелый случай, и нужно копать отдельно, сравнивать параметры и т.д.
Когда snapshot-тесты ожидаемо ломаются в процессе изменения самого компонента, мы просто генерируем новые картинки. А неожиданно snapshot-тесты у нас ломаются в худшем случае раз в несколько месяцев. Поэтому это совсем ненапряжно.
Если бы поток падений был сильнее, мы бы скорее в сторону генерации на CI более удобных репортов смотрели, чтобы сразу можно было посмотреть diff картинок.
Мы не пишем один большой тест, покрывающий все возможные кейсы. Обычно пишем несколько тестов с группой параметров, у которых сильная взаимосвязь. Например, style + isDisabled + isPressed, чтобы проверить все варианты покрасок компонента. На текущий момент количество картинок для каждого компонента не больше 130. Почти все наши snapshot-тесты — это unit-тесты, поэтому время прогона увеличилось на несколько секунд. Если добавить UI-тесты, то счёт уже пойдёт на минуты, так как UI-тесты медленные.
Про мегатест уже ответил в пункте 1. Если что-то падает, то обычно смотрим на дифф в гите, там уже примерно понятно, что сломалось. Если нужны детали - приходится копаться в именах, что да, не очень удобно. Но на практике это приемлемо т.к. тесты ломаются у нас довольно редко. Ещё была идея формировать одну большую картинку из нескольких состояний, но здесь можем столкнуться с проблемой частых обновлений картинки. Поэтому пока остановились на текущем варианте с множеством мелких картинок.
В общем случае да, булевские переменные не стоит использовать для синхронизации. В данном конкретном примере это допустимо, т.к. использование дополнительных механизмов синхронизации усложнило бы понимание кода. Так как пример именно про то, в каком порядке будут выполняться таски. Теоретически можно было бы добавить пример решения подобной проблемы средствами GCD, например, но это не совсем тема статьи.
В среднем 3-4 теста на компонент. Картинок в одном тесте порядка двух-трёх десятков. Например, у нас самый богатый на свойства компонент это
Button. У него общее количество сгенерированных картинок - 120, тестов - 6, в одной пачке примерно 20 картинок.А названия отдельных тестов и их структура тут мало решают на самом деле при починке. Проще сразу пробежаться глазами по диффу картинок. По нему сходу более-менее всё понятно.
На практике это обычно выглядит так:
На CI неожиданно упали snapshot-тесты.
Прогоняем локально с включенным
record: true. Фреймворк перезаписывает изменившееся.Смотрим по гиту изменившиеся картинки. Тот же Fork (гит клиент), например, удобен тем, что умеет diff картинок делать разными способами. Можно любые сдвиги до пикселей разглядеть. Тут уже обычно понятно, что сломалось в 99% случаев. Ниже приложил пару скринов из Fork'а.
Если изменения логичные и оправданные - просто коммитим вновь сгенерированные картинки.
Если неоправданные и что-то сломалось - идем править.
Если непонятно какие изменения в коде сломали тесты - полезно опять же гитом сделать diff кода от последнего стабильного состояния для папки с кодом компонента - тут ловится еще 1% сложных случаев.
Если все равно непонятно - тогда это уже совсем тяжелый случай, и нужно копать отдельно, сравнивать параметры и т.д.
Когда snapshot-тесты ожидаемо ломаются в процессе изменения самого компонента, мы просто генерируем новые картинки. А неожиданно snapshot-тесты у нас ломаются в худшем случае раз в несколько месяцев. Поэтому это совсем ненапряжно.
Если бы поток падений был сильнее, мы бы скорее в сторону генерации на CI более удобных репортов смотрели, чтобы сразу можно было посмотреть diff картинок.
Мы не пишем один большой тест, покрывающий все возможные кейсы. Обычно пишем несколько тестов с группой параметров, у которых сильная взаимосвязь. Например,
style + isDisabled + isPressed, чтобы проверить все варианты покрасок компонента.На текущий момент количество картинок для каждого компонента не больше 130. Почти все наши snapshot-тесты — это unit-тесты, поэтому время прогона увеличилось на несколько секунд. Если добавить UI-тесты, то счёт уже пойдёт на минуты, так как UI-тесты медленные.
Про мегатест уже ответил в пункте 1. Если что-то падает, то обычно смотрим на дифф в гите, там уже примерно понятно, что сломалось. Если нужны детали - приходится копаться в именах, что да, не очень удобно. Но на практике это приемлемо т.к. тесты ломаются у нас довольно редко. Ещё была идея формировать одну большую картинку из нескольких состояний, но здесь можем столкнуться с проблемой частых обновлений картинки. Поэтому пока остановились на текущем варианте с множеством мелких картинок.
Спасибо, мы посмотрим.
В общем случае да, булевские переменные не стоит использовать для синхронизации. В данном конкретном примере это допустимо, т.к. использование дополнительных механизмов синхронизации усложнило бы понимание кода. Так как пример именно про то, в каком порядке будут выполняться таски. Теоретически можно было бы добавить пример решения подобной проблемы средствами GCD, например, но это не совсем тема статьи.