А еще критерий, если ищешь проект и там Cypress и к примеру Typescript, то больше шансов что программисты понимают и в тестировании и в программировании.

coffescript -> JS -> TS  это же замечательная эволюция

отличный вброс)

Судя по тому что слышу на собесах - такая же лотерея как и с другими инструментами. То что кто-то выбрал инструмент Х не делает их понимание тестирования лучше. Выглядит даже наоборот - его часто берут новички (потому что хайп и easy painless testing... for developers) и лепят такую дичь, что на голову не налазит.

А можете сформулировать критерии дичи?
Формально - тесты есть, бегают, задачу бизнеса решают)

Любимый топ-3:
- хочу получить текст из элемента в переменную
- циклами итерируюсь по массиву элементов для поиска одного
- пихаю чейнабл в переменную и заворачиваю в await

Довольно удобно, да

Задача решена, но не решена оптимально. И кажется лучшее что мы можем делать -  писать статьи, показывать и рассказывать как инженерно решать такие штуки.

из моей позавчерашней статистики

Я считаю тот инструмент хорош который будет спарвялятся с задачами паралеллизации и конфигурации набора тестов наиболее удобным спобом желательно бесплатно доступным.
Пока я не видел JS раннеров (не BDD) которые бы могли тесты маркировать тегами как тот же Java TestNG с его мощью генерации сьютов и маркировки зависимости тестов а также параллелизации.
В JS мире - это в основном тыкалки по кнопкам в том или ином виде с примитивными раннерами

Selenium Grid пока наиболее доступное решение для вопросов распеределения выполнения тестов и его можна развернуть в том же k8s кластере - всё остальное это попытка пересадить автоматизаторов на платные проекты

Связка wdio + Selenium Grid - JS самое оптимальное классическое решение

чем же Selenoid + GGR не подходит для паралеллизации, куда эффективние

1.3.1. Selenoid in Kubernetes
We are very frequently asked whether it is possible to run Selenoid in Kubernetes cluster. The answer is - it is possible but we do not recommend doing this:

Selenoid can only work directly with Docker API and was created to be run on a workstation or a virtual machine with Docker installed.

Kubernetes contrarily has a completely different API and can be using Docker as a container runtime backend. In some clusters rkt is used instead of Docker and in that case Selenoid will not work.

Even if Selenoid works - all browser containers will be started on the same Kubernetes node where it is running.

So far as Selenoid is using Docker API directly - Kubernetes will not be aware of additional containers started by Selenoid. This is dangerous and can potentially lead to overloaded Kubernetes nodes.

You can only have one Selenoid replica maximum. This is because Selenoid internally stores a list of running sessions in memory.

если вы о Moon - то да но там лимит в 4 потока - потом плати

Moon тоже отличный вариант, нам 4 потока хватает. Но это немного другое - https://github.com/aerokube/ggr

в системе где бегают 1000+ тестов там и 10 потоков не хватает )

Виталий вы говорите о том случае если у вас есть отдельный хост с докером или связка хостов. Я же говорю о современном мире где у тебя есть kubectl как точка входа в k8s кластер