Comments 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
Sign up to leave a comment.
Эволюция стратегий тестирования — хватит быть обезьяной