Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 12
Кажется, не имело смысла разбивать на несколько частей. Или хотя бы, надо было кратко раскрыть содержание второй части.
Согласен. Не очень приятно читать текст типа «Вот тут у нас проблема, и тут проблема, тут криво, тут долго». Окей, какие варианты решения? Их нет, ждите дальше.
Согласен, следующие части выйдут очень скоро. Но я считаю что путь чужих ошибок и «как не нужно делать» тоже достаточно интересен, кроме того тут описаны проблемы самого классического пути автоматизации тестирования.
«В конце концов наш тестовый код стал реально сложным и только несколько человек в команде понимали как работает эта магия.» — Я попадал в похожую ситуацию. Все стало настолько сложным, что тестам были нужны свои собственные тесты. В следующий раз хочу попробовать другой подход — никаких гераторов данных, а только готовые дампы базы.
С дампами данных можно прийти в другую крайность. Синтетически всё выглядит работоспособным, а на деле падает.
А вообще у тестов должна быть своя архитектура, DRY, KISS и прочее.
Ну и разумеется Unit -> Feature -> Поведенческие.
А вообще у тестов должна быть своя архитектура, DRY, KISS и прочее.
Ну и разумеется Unit -> Feature -> Поведенческие.
Синтетически всё выглядит работоспособным, а на деле падает.
Такое часто происходит если база пришла из продакшена в тесты без промежуточной статической проверки. То есть никто не убедился в том, что там на самом деле всё правильно и нет намеков на то, что какие-либо проверки или ограничения на самом деле почему-то не соблюдаются.
Мы пришли к тому, что использовать дампы — плохая стратегия.
Во-первых, если «делить» дамп между тестами, то тесты начинают менять глобальное состояние и прямо или косвенно влиять друг на друга (задизейблил один тест и пять других упало, потому что они были зависимы от измененного состояния этого теста).
Поднимать чистый дамп для каждого теста в больших системах не представляется возможным с точки зрения быстродействия.
Мы пошли по пути того, что каждый тест обязан приготовить данные перед своим началом и полностью очистить их после себя. Не всегда это сделать просто, но в большинстве случаев это оправдано и в таком случае тесты становятся полностью независимыми и идемпотентными.
Во-первых, если «делить» дамп между тестами, то тесты начинают менять глобальное состояние и прямо или косвенно влиять друг на друга (задизейблил один тест и пять других упало, потому что они были зависимы от измененного состояния этого теста).
Поднимать чистый дамп для каждого теста в больших системах не представляется возможным с точки зрения быстродействия.
Мы пошли по пути того, что каждый тест обязан приготовить данные перед своим началом и полностью очистить их после себя. Не всегда это сделать просто, но в большинстве случаев это оправдано и в таком случае тесты становятся полностью независимыми и идемпотентными.
Начинается это с добавлением sleep'а на 300мс в одном месте, потом на 1 секунду в другом, затем на 3 секунды.
На каком именно фреймворке писались тесты? sleep — действительно очень плохое решение. Нужно ожидать результата асинхронного действия по таймауту. В Nightwatch.js это делается с помощью waitForElementVisible или waitForElementPresent.
Мы используем Protractor, и конечно же использование слипов плохая идея. Но по нашему опыту в некоторых случаях очень сложно отследить когда операция выполнена успешно.
И поскольку тесты не стабильны, разработчики думают «ну, что-то происходит слишком быстро, поставлю ка я тут слип, оно станет стабильнее». Сначала это происходит в одном месте, потом в еще одном, потом в еще одном. И дальше как снежный ком.
И поскольку тесты не стабильны, разработчики думают «ну, что-то происходит слишком быстро, поставлю ка я тут слип, оно станет стабильнее». Сначала это происходит в одном месте, потом в еще одном, потом в еще одном. И дальше как снежный ком.
После использования Protractor'а около года у меня начали периодически возникать мысли о том, что использование Protractor'а в целом идея не очень. Очень тяжело давалась стабилизация. В итоге удалось заметно стабилизировать тесты максимально избегая sleep'ов, правда для этого пришлось перелопатить весь фреймворк. Сейчас всё еще не идеально, но false negative не более 3% за 4 часа ночных прогонов на Grid'е. И, к сожалению, тут уже сложно что-то существенное сделать.
P.S.: Фреймворк с самого начала писал не я, поэтому на Grid'е он с самого начала давал около 80% failed
P.S.: Фреймворк с самого начала писал не я, поэтому на Grid'е он с самого начала давал около 80% failed
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Эволюция стратегий тестирования — хватит быть обезьяной