ВС
просто у яндекса часто плохо с документацией
я им там ишью завел что не могу завести их вундервафлю - они доку подправили
Size: a a a
2019 December 18
BO
а gemini разве не deprecated? В том смысле, что его не поддерживают?
deprecated
ВС
deprecated
гермиона теперь вместо него?
ВС
ну там они минимально отличаются, для юзера
BO
да. но там не так все хорошо как в gemini. не так давно статью читал где-то
ВС
принцип один фиг похож
B
deprecated
Но он вполне юзабелен
BO
Но он вполне юзабелен
ага с 4 wdio под капотом))
AP
На джест + кукловод видел хорошее решение, которое можно дополнить уже самому
Какое?
B
И самостоятельно тоже
B
Какое?
До компа дойду -напишу. Если не забуду
OK
сегодня меня пристыдил протрактор - пишет Shame...
AP
Он сам понимает что пользоваться им стыдно должно быть)
OK
Он сам понимает что пользоваться им стыдно должно быть)
а какие подводные камни юзать и selenidejs и голый protractor в одном проекте? Не хочу переписывать старый код
AP
а какие подводные камни юзать и selenidejs и голый protractor в одном проекте? Не хочу переписывать старый код
Все камни трактора как тест раннера, больше нет
AP
По факту как было так и останется, в плане костылей
OK
Все камни трактора как тест раннера, больше нет
угу, понял
E
Всем привет, кто знает как заимпортить js модули из другого проекта, все проекты лежат в одной папке?
2019 December 19
VG
но до поддержки его руки не дошли, прозреваю что со сравнением картинок будет маленький адок в плане организации процессов
адок будет если будете пилить решения на всяких gemini / germione / итд (поверьте - есть опыт уже с этим подходом).
На предыдущей работе мы успешно внедрили jest-image-snapshot.
Но для этого есть несколько предусловий:
1) эти тесты должны быть в репозитории где находятся с реакт компоненты
2) у вас выстроен процес PR-ов с код ревью и CI гоняет тесты на каждом PR (если скрины обновлились - это будет видно в PR-e).
3) вы будете писать тесты для реакт компонент, которые рендерятся в изоляции с фейковыми данными на входе
Если все 3 условия выполняются, и у вас в команде адекватные люди, то обяснить даже на пальцах преимущества этого подхода будет не тяжело. С вашей стороны не нужно будет делать ровно ничего для поддержки этих тестов и скринов в долгострочной перспективе (это будут делать сами девелоперы). Вопрос только в том какие у вас цели - выстроить нормальные “quality gates” в процесе поставки вашего продукта, или обеспечить себе job security (за счет написания еще одного велосипеда где-то сбоку от проекта, о котором никто кроме вас не будет ничего понимать).
На предыдущей работе мы успешно внедрили jest-image-snapshot.
Но для этого есть несколько предусловий:
1) эти тесты должны быть в репозитории где находятся с реакт компоненты
2) у вас выстроен процес PR-ов с код ревью и CI гоняет тесты на каждом PR (если скрины обновлились - это будет видно в PR-e).
3) вы будете писать тесты для реакт компонент, которые рендерятся в изоляции с фейковыми данными на входе
Если все 3 условия выполняются, и у вас в команде адекватные люди, то обяснить даже на пальцах преимущества этого подхода будет не тяжело. С вашей стороны не нужно будет делать ровно ничего для поддержки этих тестов и скринов в долгострочной перспективе (это будут делать сами девелоперы). Вопрос только в том какие у вас цели - выстроить нормальные “quality gates” в процесе поставки вашего продукта, или обеспечить себе job security (за счет написания еще одного велосипеда где-то сбоку от проекта, о котором никто кроме вас не будет ничего понимать).
ВС
адок будет если будете пилить решения на всяких gemini / germione / итд (поверьте - есть опыт уже с этим подходом).
На предыдущей работе мы успешно внедрили jest-image-snapshot.
Но для этого есть несколько предусловий:
1) эти тесты должны быть в репозитории где находятся с реакт компоненты
2) у вас выстроен процес PR-ов с код ревью и CI гоняет тесты на каждом PR (если скрины обновлились - это будет видно в PR-e).
3) вы будете писать тесты для реакт компонент, которые рендерятся в изоляции с фейковыми данными на входе
Если все 3 условия выполняются, и у вас в команде адекватные люди, то обяснить даже на пальцах преимущества этого подхода будет не тяжело. С вашей стороны не нужно будет делать ровно ничего для поддержки этих тестов и скринов в долгострочной перспективе (это будут делать сами девелоперы). Вопрос только в том какие у вас цели - выстроить нормальные “quality gates” в процесе поставки вашего продукта, или обеспечить себе job security (за счет написания еще одного велосипеда где-то сбоку от проекта, о котором никто кроме вас не будет ничего понимать).
На предыдущей работе мы успешно внедрили jest-image-snapshot.
Но для этого есть несколько предусловий:
1) эти тесты должны быть в репозитории где находятся с реакт компоненты
2) у вас выстроен процес PR-ов с код ревью и CI гоняет тесты на каждом PR (если скрины обновлились - это будет видно в PR-e).
3) вы будете писать тесты для реакт компонент, которые рендерятся в изоляции с фейковыми данными на входе
Если все 3 условия выполняются, и у вас в команде адекватные люди, то обяснить даже на пальцах преимущества этого подхода будет не тяжело. С вашей стороны не нужно будет делать ровно ничего для поддержки этих тестов и скринов в долгострочной перспективе (это будут делать сами девелоперы). Вопрос только в том какие у вас цели - выстроить нормальные “quality gates” в процесе поставки вашего продукта, или обеспечить себе job security (за счет написания еще одного велосипеда где-то сбоку от проекта, о котором никто кроме вас не будет ничего понимать).
У нас тима пишет код для фичи, которая встраивается в страницы, написанные другими тимами. Вот даже не знаю, при таком раскладе, стоит ли писать тесты на компоненты в изоляции...
На счет прогонов на каждый пр - это конечно удобно и понятно в целом, не зависимо от типа тестов. Но что там у вас происходит со скринами в пр я не совсем понял, можно уточнить?
На счет прогонов на каждый пр - это конечно удобно и понятно в целом, не зависимо от типа тестов. Но что там у вас происходит со скринами в пр я не совсем понял, можно уточнить?