Три года автотестов: как повысить скорость и не только

[amakhrov]

Для MySQL я использовал

innodb_flush_log_at_trx_commit = 0

Тоже заметно сокращало время работы тестов. Может, кому пригодится.

[villiwalla]

А чем тестируется UI, Selenium?

[anzem]

UI пытались тестировать с помощью phantomjs и headless chrome, тогда использовали Codeception framework для этого. Для ангуляра — Protractor. Но в итоге отказались от UI тестов из-за частых false positive срабатываний и очень низкой скорости.

[alexkrash]

Мы у себя такую используем самопал — DbMocks, подробности тут:
habr.com/ru/company/badoo/blog/443768
Если у вас у таблицы foreign key и триггеры, то это несколько сложнее, но раз уж вы научились это транслировать в SQLite, то наверное и свой DbMocks сделаете :)

[C4ET4uK]

Я если честно не силен в php, но насколько я понял автор называет главной проблемой моков —

Второй обнаруженный минус состоит в том, что тесты стали менее надежны. Они «не замечают» даже изменения интерфейса, не говоря уж о реализации.

В языках со статической типизацией мок наследуется от интерфейс и если вдруг что-то пропало — просто не скомпилируется. То есть это проблема не моков, а PHP?

[ApeCoder]

Это зависит от, того, что считать моком и как он реализован. В статически типизированном языке можно динамически генерить моки а волшебство зафигачит Not Implemented Exception, например, во все методы кроме явно указанных.

https://habr.com/ru/post/150859/

[anzem]

C4ET4uK Верно подмечено, если бы 1) мы писали на статически-типизированном языке и 2) добавили бы небольшой оверхед в виде интерфейсов на каждый класс, на который нужен мок, то да, эта проблема бы ушла. И всё же, это не главная проблема. Для нас очень важен подход разработки через тестирование, которые меняет мышление — заставляет отвлечься от деталей реализации и подумать о конечном результате. Моки ломают этот настрой — заставляли задумываться о реализации. Это серьёзный недостаток.

[BogdanH]

У нас на проекте около 4000 тестов, поведенческие, функциональные, модульные. Могу сказать из своего опыта, что более всего важны функциоальные тесты, практика черного ящика, не важно как система организована внутри, главное чтобы при передачи данных она вернула ожидаемый ответ. И да, никогда, никогда не используйте SQLite :D Система должна тестироваться с базой с которой она работает в лайве, рано или поздно вы словите неприятную ошибку, что тест падает, а функицонал работает, потом окажется, что SQLite не поддерживает что-то из MySQL или PostgreSQL.

[anzem]

BogdanH Согласен, мы, кстати, тоже пришли к выводу, что функциональные тесты наиболее полезны при разработке

[OperatorPEVM]

На прошлой работе также столкнулись с тем, что веб-драйвера не обнаруживали некоторые элементы, которые мы видели глазами. Сейчас это, наверное, исправлено, а тогда пришлось от них отказаться.

По поводу этой пролемы- в самом селениуме это не исправлено до сих пор. Но нашлись умные ребята, которые написали надстройку на Java, называется Selenide. Она эту проблему решает. Лично использовал ее порты под питон (Selene) и .NET. — NSelene. Работает отлично, да и куда она денется, собственно настройка заточена под решение данной проблемы.

[SoftwareEngineerInTest]

Спасибо за наводку

[ludoweek]

Спасибо. Надо будет подумать над этим.

[Slonopotamych]

СУБД SQLite, она умеет создавать БД в оперативной памяти

Постгря тоже может работать с такой БД, если БД создана на RAM-диске. Если тесты гоняются с использованием окружения докер-композ, то нет особых сложностей подготовить докерфайл постгри, который мапит RAM-диск и БД создает в нем.

[anzem]

Есть какие-то цифры? Во сколько раз это даёт ускорение?

[Slonopotamych]

В нашей ситуации это примерно в два раза, но тут, я думаю, все будет сильно зависеть от типа нагрузки на БД в тестах.

[anzem]

а fsync, synchronous_commit, full_page_writes отключены у вас?

[Slonopotamych]

Пока нет, но возможно они не будут иметь существенного эффекта, с учетом того, что БД работает в оперативной памяти.