Комментарии 23
Мы используем MBT и graphwalker.— сразу распишите, какие модули допиливать в самом graphwalker, т.к чистый инструмент нас не устроил и пришлось дорабатывать.
Плюс про визуализатор обхода.
Есть мок сервер на Go, возможно вам больше понравится
https://github.com/jmartin82/mmock
В остальном мы используем обычные инструменты для тестирования: API тесты связкой Kotlin+JUnit+RestAssured
Чем обусловлен выбор этого стека? Во-первых, компилируемый язык плохо подходит для тестов, во-вторых, джавы в холде на техрадаре.
Java в холде на техрадаре, но есть Kotlin (пынь).
Есть, но в андроиде, тут же речь не о нем, как я понял.
Почему вы считаете, что компилируемый язык плохо подходит для тестов?
Ну потому что тест – это простой прямолинейный сценарий, для этого существуют скриптовые интерпретируемые языки. Не надо ждать компиляции всего мира, проще запускать по-отдельности, чаще всего в случае с тестами потребляют меньше ресурсов, не нужны знания об огромном джава мире
По поводу стека для api тестов, выбор был обоснован, по большей части, уже имеющимися UI тестами на Kotlin (к моменту моего прихода в компанию) и моим собственным опытом разработки подобных фреймворков с использованием этого языка.
На счет обязательного использования скриптовых языков для написания тестов — не соглашусь, но думаю любые мои аргументы в пользу компилируемых языков неизбежно приведут к холивару который закончится ничем.
Про обязательное я не говорил, выше есть хороший аргумент, когда их вполне можно использовать. Опять же опыт команды тоже играет роль.
А что за UI тесты на котлине? Graphwalker+Android или ещё что-то?
На техрадаре нет раздела QA, потому что его оттуда выпилили и он там, имхо, не нужен. Все можно закинуть в имеющиеся разделы.
Что делать с тем, что вся компания использует другой стек для таких же тестов?
И, кстати, как вы их запускаете?
Про UI тесты на Котлине с использованием Graphwalker будет отдельная статья. Пока не буду спойлерить.
Не думаю, что добавлять технологии используемые в тестировании в раздел Backend или еще куда либо, кроме как в раздел технологий используемых в тестировании, будет хорошей идеей, имхо.
Что вы имеете ввиду под формулировкой — такие же тесты?
Запускаем через Teamcity.
Я про вот этот комментарий
Не думаю, что добавлять технологии используемые в тестировании в раздел Backend или еще…
Я бы просто не стал отделять тестирование от разработки.
Что вы имеете ввиду под формулировкой — такие же тесты?
Функциональные e2e. Апи или UI – не так важно.
Запускаем через Teamcity.
В тимсити только кнопка нажиматся, главная магия всегда не в нем :)
Я бы просто не стал отделять тестирование от разработки.
Неплохой вариант.
Функциональные e2e. Апи или UI – не так важно.
Изменения в стеке имеют место, если они обоснованы. Их обоснование обычно ложится на плечи того, кто собирается внедрить эти изменения. У меня получилось.
Ну и конечно стоит отметить, что Автотека все же отдельный проект. И эти изменения туда внедрять несколько проще.
В тимсити только кнопка нажимается, главная магия всегда не в нем :)
Да, все именно так. С помощью Maven запускаем тесты с использованием JUnit. Тимсити JUnit report отлично умеет парсить и показывать в читаемом виде, того что здесь написано — хватит для первоначальной настройки.
Привет
Наткнулся на ваш форк GraphWalker и на эту статью. Вижу что форк давно не обновлялся, плюс статьи про MBT так и не было. Подскажите пожалуйста как у вас сейчас с этим обстоит.
Здравствуйте! Отказались от MBT в итоге из-за высокой сложности и порога входа. То есть условно, для маленького проекта, каким была Автотека на тот момент - это было норм. Но для Авито например, или даже для текущей Автотеки это слишком сложно поддерживать, а профита сильного нет по сравнению с обычным подходом.
Как тестируют в Автотеке: MindMap’s, статический анализ кода и MockServer