Здравствуйте! Отказались от MBT в итоге из-за высокой сложности и порога входа. То есть условно, для маленького проекта, каким была Автотека на тот момент - это было норм. Но для Авито например, или даже для текущей Автотеки это слишком сложно поддерживать, а профита сильного нет по сравнению с обычным подходом.
Я бы просто не стал отделять тестирование от разработки.
Неплохой вариант.
Функциональные e2e. Апи или UI – не так важно.
Изменения в стеке имеют место, если они обоснованы. Их обоснование обычно ложится на плечи того, кто собирается внедрить эти изменения. У меня получилось.
Ну и конечно стоит отметить, что Автотека все же отдельный проект. И эти изменения туда внедрять несколько проще.
В тимсити только кнопка нажимается, главная магия всегда не в нем :)
Да, все именно так. С помощью Maven запускаем тесты с использованием JUnit. Тимсити JUnit report отлично умеет парсить и показывать в читаемом виде, того что здесь написано — хватит для первоначальной настройки.
Если честно — не увидел хорошего аргумента, не могли бы его привести?
Про UI тесты на Котлине с использованием Graphwalker будет отдельная статья. Пока не буду спойлерить.
Не думаю, что добавлять технологии используемые в тестировании в раздел Backend или еще куда либо, кроме как в раздел технологий используемых в тестировании, будет хорошей идеей, имхо.
Что вы имеете ввиду под формулировкой — такие же тесты?
Запускаем через Teamcity.
По поводу техрадара, там нет раздела QA, он на этапе формирования. Спасибо за замечание.
По поводу стека для api тестов, выбор был обоснован, по большей части, уже имеющимися UI тестами на Kotlin (к моменту моего прихода в компанию) и моим собственным опытом разработки подобных фреймворков с использованием этого языка.
На счет обязательного использования скриптовых языков для написания тестов — не соглашусь, но думаю любые мои аргументы в пользу компилируемых языков неизбежно приведут к холивару который закончится ничем.
Здравствуйте! Отказались от MBT в итоге из-за высокой сложности и порога входа. То есть условно, для маленького проекта, каким была Автотека на тот момент - это было норм. Но для Авито например, или даже для текущей Автотеки это слишком сложно поддерживать, а профита сильного нет по сравнению с обычным подходом.
Привет! Правильно я понимаю, что в рамках сессии нужно будет писать автотесты?
Неплохой вариант.
Изменения в стеке имеют место, если они обоснованы. Их обоснование обычно ложится на плечи того, кто собирается внедрить эти изменения. У меня получилось.
Ну и конечно стоит отметить, что Автотека все же отдельный проект. И эти изменения туда внедрять несколько проще.
Да, все именно так. С помощью Maven запускаем тесты с использованием JUnit. Тимсити JUnit report отлично умеет парсить и показывать в читаемом виде, того что здесь написано — хватит для первоначальной настройки.
Про UI тесты на Котлине с использованием Graphwalker будет отдельная статья. Пока не буду спойлерить.
Не думаю, что добавлять технологии используемые в тестировании в раздел Backend или еще куда либо, кроме как в раздел технологий используемых в тестировании, будет хорошей идеей, имхо.
Что вы имеете ввиду под формулировкой — такие же тесты?
Запускаем через Teamcity.
По поводу стека для api тестов, выбор был обоснован, по большей части, уже имеющимися UI тестами на Kotlin (к моменту моего прихода в компанию) и моим собственным опытом разработки подобных фреймворков с использованием этого языка.
На счет обязательного использования скриптовых языков для написания тестов — не соглашусь, но думаю любые мои аргументы в пользу компилируемых языков неизбежно приведут к холивару который закончится ничем.
Java в холде на техрадаре, но есть Kotlin (пынь).