Alexej Simakov

Стурктуру - нет. Это как у машины четыре колеса и руль. Иконки и цветовую палитру, а также уникальные функциональные особенности - да.
почитайте еще это

Профессионализм = 1/пофигизм.
Вот и вся градация. Ты можешь миллион лет работать на позиции тестировщика - если полезного выхлопа от тебя мало - не о чем говорить.
В моем представлении джун - ведомое существо. Не пнешь - не полетит. Если он становится самостоятельным - это мид (сам выбирает правильные задачи, сам их выполняет). И когда он может пинать других - это сениор. Но это так, имхо.

"$1"
Обоснование: пока вы придумываете название классам - индусы деплоят свои поделки на продакшн.

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

вот тут еще говорят что это не столько высокое разрешение (что все мелкое) а то что монитор глянцевый, а не матовый.

может включить subpixel antialiasing? там как раз говорится что в mojave он по умолчанию отключен, что может создать именно описываемый вами эффект "размытости" на экранах с низким разрешением (уже full hd стало низким разрешением, дожили .., но тем не менее).

https://www.iamcal.com/misc/bf_debug/
https://github.com/iamcal/brainfuck-debug

Короткий ответ:
Если вы будете тесты "накликивать" то у вас и тесты будут ломаться после каждого изменения, в итоге вы только потеряете время. Кликалки используют абсолютные локаторы - это заведомый ад. Но чтобы не оставлять вопрос без прямого ответа .. что мне там попадалось не так давно ... testcafe, katalon studio, cypress.io

Длинный ответ:

без тестов само собой все ломается после каждого коммита

Так не должно быть. У вас какая-то изначальная проблема с качеством кода приложения. Я не специалист по js но скорее всего вы не используете распространенные архитектурные шаблоны. Если у вас код следует каким то правилам то он так просто не ломается от коммита. Бажный коммит просиходит от непонимания внутреннего устройства приложения. Не хочу Вас обидеть - определенной долей непонимания обладают даже самые опытные разработчики. Надо эту долю уменьшать.

вручную как то очень затратно по времени

Вообще разработка программного обеспечения очень затратная вещь. А написание качественного ПО - еще более затратная.

Хотите потратить время с пользой - лучше напишите список функциональных требований к приложению, что оно должно уметь. Когда окончите строгать свою поделку пройдетесь по сценариям, и дополнительно проверите что работают краевые случаи, кроссбраузерность, перформанс и пр. Для приложения такого масштаба этого будет вполне достаточно. Автоматизация тестирования как правило не окупается на мелких краткосрочных проектах.

В английском это называется duct tape programming - программирование "изолентой".
Это значит мы записываем в код первое пришедшее в голову решение, не раздумывая, не задумываясь о последствиях и пр. Главное чтобы было "сделано".
Еще указывают на проблему такого подхода, что человек который делает тяп-ляп, но быстро в глазах заказчика или менеджера будет незаслуженно выглядеть героем.

Вот в этой презентации
(Robert Johnson, Smartodds Ltd. "An introduction to football modelling at Smartodds", Oxford SIAM Conference 2011)
можно получить общее представление как делают вероятностную модель исхода футбольного матча:

Также в конце слайдов есть ссылки на источники, их тоже изучите.

Нужен аккаунт на гитхабе и аккаунт на EpicGames. Надо привязать аккаунт гитхаба в настройках профиля в EpicGames, тогда вы получите приглашение в гитхабе вступить в их группу и получите доступ к приватному репозиторию тут:
https://github.com/EpicGames/UnrealEngine

Вся процедура описана тут , тут и тут

https://github.com/erilyth/Flappy-Bird-Genetic-Alg...

В чем именно вы хотите убедиться? Какой тип ошибки вы хотите поймать? По определению асинхронная функция совершенно законно может вернуть ошибку если промис не был выполнен в заданный промежуток времени. Тут тест по моему опыту бесполезен.
T.e. нужно спросить себя "какую полезную информацию я получу если этот тест упадет?". Никакой - ваш "невод" может законно вернуться с "тиной морскою". Это природа промиса.
Другое дело если вы хотите убедиться в том что не изменился path. Для этого нужен тест на путь. Вроде test_path_available

Чтобы тест давал полезную информацию должно произойти что-то чего тест не ожидал. Например поменялся интефейс Application и функция load стала называться load_path. Тогда ваш тест отвалится и вы заметите изменение. Проверять что вы получите отказ если вы можете получить отказ - бессмысленно.
Простите что три раза об одном и том же разными словами, но это важный момент при дизайне тестов.
Опять же если вы хотите проверить за какое время вы получаете ответ - это имеет смысл, но это область нагрузочного тестирования.

Автоматизатор (неважно выделенный он человек или по совместительству) должен быть в курсе что меняется в системе и соответственно адаптировать тесты. А в чем собственно проблема?
Этот вывод напрашивается сам собой, если рассматривать тесты как программу или программную систему специального назначения. Тестируемая программа (SUT) это данные которые приходят ей на вход. Если данные меняются таким образом, что программная система перестает правильно их обрабатывать необходимо адаптировать программную систему.

Ищите по запросу "how to game bots". на Хабре поищите по запросу "пишем бота игры"
Игровые боты наверное одна из самых сложных отраслей автоматизации, поэтому если освоить это, то можно будет автоматизировать любое приложение.

Вот вам парочку полезных статей для начала:
https://habr.com/post/339596/ История взлома всех игр в Telegram
https://habr.com/company/yandex/blog/336476/ Десктопные GUI-тесты на Python. Лекция в Яндексе

драйвера на графической карте и/или DirectX обновляли?
Можно еще в саппорт обратиться - программа все-таки не сильно распространенная.

Я думаю можно что-то такое сделать. Итератор над списком пользователей гарантирует что каждая запись будет задействована только один раз.

import java.util.Arrays;
import java.util.Iterator;
public class Main {
  public static void main(String[] args) {
    User foo[] = { new User(1), new User(2), new User(3), new User(4)};
    Iterable<User> userlist = Arrays.asList(foo);
    Iterator userpool = userlist.iterator();
    while(userpool.hasNext()){
     Starter.startTestWithUser((User)userpool.next());
    }
  }
}
class User{
  private int id;
  public User(int id){ this.id = id;  }
  public int id(){ return this.id;  }
}
class Starter{
  public static void startTestWithUser(User user){
    System.out.println("Creating Test for user "+user.id());
  }
}

Например все типы артефактов и задач получают свою компоненту. Модели, текстуры(это и скины тоже), анимация, полиграфия, медиа, звук. Или сделайте общую компоненту маркетинг для печатной продукции и веб сайта.
Например на маленьком сайте у нас было так "графика, текст, верстка, скрипты, база данных".
Обычно я рапределяю по тому в каком месте нужно над этим работать: работы отверточные, работы молоточные, покрасочные. Тогда задачи по компонентам будет легче группировать и обрабатывать в один заход.
Сборка это этап разработки перед выкатом продукта, другое дело если у вас есть сервер который нужно настраивать, тогда это "конфигурация" или "devops" или deployment или предрелизная подготовка, например. Надо продумать компоненты так, чтобы под каждую задачу или баг нашелся свой горшочек, чтобы не было такого что "ну оно как бы и туда и туда относится". Все.

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

И вот еще дам вам ссылку на серию статей, которые мне в свое время очень пришлись по вкусу своей обстоятельностью:
https://habr.com/post/247333/

писал ее, когда совсем почти ничего не знал

может довести ее до ума?
Ведь нехватает всегда не знаний, а настойчивости, целеустремленности и терпения.