SM
Почему?
Не будет ответа на вопрос 'где именно поломалось', а это важно в более-менее сложном проекте
Size: a a a
2020 November 11
SM
Как следствие, неоправданно много времени будет уходить на локализацию проблемы
R(
Интеграционные тесты компонентов друг с другом, да
Но это всё равно UI тесты
Вопрос в том, что имярек не до конца понимает разницу между UI и E2E
Но это всё равно UI тесты
Вопрос в том, что имярек не до конца понимает разницу между UI и E2E
> Но это всё равно UI тесты
Нет :) Совершенно не обязательно UI.
Нет :) Совершенно не обязательно UI.
IC
Не будет ответа на вопрос 'где именно поломалось', а это важно в более-менее сложном проекте
Окей, то есть у нас время на поиск проблемы против времени на написание и поддержание юнит-тестов. Мне пока неочевидно, что первое время больше. Продолжайте.
SM
> Но это всё равно UI тесты
Нет :) Совершенно не обязательно UI.
Нет :) Совершенно не обязательно UI.
Что с чем мы интегрируем в UI проекте?
Я это вижу как-то так для UI проекта:
1. Компоненты внутри с юнит тестами
2. Компоненты снаружи UI тесты на моках
3. Интеграционные, UI на моках
Я это вижу как-то так для UI проекта:
1. Компоненты внутри с юнит тестами
2. Компоненты снаружи UI тесты на моках
3. Интеграционные, UI на моках
SM
Окей, то есть у нас время на поиск проблемы против времени на написание и поддержание юнит-тестов. Мне пока неочевидно, что первое время больше. Продолжайте.
Что продолжать?
Рассказывать теорию автоматизации тестирования ? :)
Рассказывать теорию автоматизации тестирования ? :)
IC
Что продолжать?
Рассказывать теорию автоматизации тестирования ? :)
Рассказывать теорию автоматизации тестирования ? :)
Лучше бы статистику какую-то, конечно. Был проект такой-то сложности (как сложность оценивается, кстати?), сперва были такие тесты, потом добавили другие, время на исправление багов изменилось так-то, время на разработку изменилось вот так.
SM
Мне очевидно, что в случае полной пирамиды время на поиск неисправности конечно и известно. А в случае одних только E2E - мы каждый раз заложники ситуации
i
Ребят,
вклинюсь немного: рекурсия же зло?
вклинюсь немного: рекурсия же зло?
IC
Мне очевидно, что в случае полной пирамиды время на поиск неисправности конечно и известно. А в случае одних только E2E - мы каждый раз заложники ситуации
Я бы посмотрел, как это согласуется с законом убывающей отдачи, например.
SM
Лучше бы статистику какую-то, конечно. Был проект такой-то сложности (как сложность оценивается, кстати?), сперва были такие тесты, потом добавили другие, время на исправление багов изменилось так-то, время на разработку изменилось вот так.
Мне очень жаль, но я не работал на проектах, где с тестами было всё настолько плохо, как ты описываешь
Бывало так, что мы начинали с E2E или частичного покрытия, но вопрос 'давайте выкинем один из уровней пирамиды тестирования и посмотрим, чем это закончится' - не стоял никогда
Бывало так, что мы начинали с E2E или частичного покрытия, но вопрос 'давайте выкинем один из уровней пирамиды тестирования и посмотрим, чем это закончится' - не стоял никогда
MK
i think it's okay
Ребят,
вклинюсь немного: рекурсия же зло?
вклинюсь немного: рекурсия же зло?
Нет
IC
i think it's okay
Ребят,
вклинюсь немного: рекурсия же зло?
вклинюсь немного: рекурсия же зло?
Код с ней проще читать зачастую. Дальше уже надо смотреть обстоятельства. Возможно ли зацикливание, переполнение стека и т.д.
i
Понял.
Спасибо
Спасибо
IC
Мне очень жаль, но я не работал на проектах, где с тестами было всё настолько плохо, как ты описываешь
Бывало так, что мы начинали с E2E или частичного покрытия, но вопрос 'давайте выкинем один из уровней пирамиды тестирования и посмотрим, чем это закончится' - не стоял никогда
Бывало так, что мы начинали с E2E или частичного покрытия, но вопрос 'давайте выкинем один из уровней пирамиды тестирования и посмотрим, чем это закончится' - не стоял никогда
Ну то есть вам очевидно, что практика, которую вы всегда использовали, лучше практики, которую не использовали никогда. Я, кстати, не настаиваю на ненужности юнит-тестов, но вот настаивание на юнит-тестах выглядит странным :)
SM
Ну то есть вам очевидно, что практика, которую вы всегда использовали, лучше практики, которую не использовали никогда. Я, кстати, не настаиваю на ненужности юнит-тестов, но вот настаивание на юнит-тестах выглядит странным :)
Много слов знаешь, производит впечатление
IC
Много слов знаешь, производит впечатление
С этим прям беда. Никак не могу научиться писать лаконично.
SM
С этим прям беда. Никак не могу научиться писать лаконично.
А вот это 'UI тесты больше покроют, чем юниты' - это прямо на скрижали, с твоего позволения
ZE
Интеграционные тесты компонентов друг с другом, да
Но это всё равно UI тесты
Вопрос в том, что имярек не до конца понимает разницу между UI и E2E
Но это всё равно UI тесты
Вопрос в том, что имярек не до конца понимает разницу между UI и E2E
это ж в связи с чем такие выводы, о любитель тестировать е2е сценарии через крайне стабильный фронтенд
R(
Что с чем мы интегрируем в UI проекте?
Я это вижу как-то так для UI проекта:
1. Компоненты внутри с юнит тестами
2. Компоненты снаружи UI тесты на моках
3. Интеграционные, UI на моках
Я это вижу как-то так для UI проекта:
1. Компоненты внутри с юнит тестами
2. Компоненты снаружи UI тесты на моках
3. Интеграционные, UI на моках
В проекте могут быть несколько модулей реализующих определённую логику совместно.
(реальный пример) Опросник который показывает те или иные вопросы в зависимости от того как пользователь ответил на предыдущие. Логика "что показать" больше юнита, и при этом независима от пользовательского интерфейса — только от модулей и данных. Вот могут быть проверки на такую логику.
(реальный пример) Опросник который показывает те или иные вопросы в зависимости от того как пользователь ответил на предыдущие. Логика "что показать" больше юнита, и при этом независима от пользовательского интерфейса — только от модулей и данных. Вот могут быть проверки на такую логику.