Владислав Копылов

1. Поднять локально на ноутбуке http cервер (гуглим, их много), узнать его ip:port
2. Быть с ноутбуком в одной локальной сети (под одним wifi роутером к пример)
3. Открыть страницу в браузере на ноутбуке по ip:port, если ок - тоже самое на 2м устройстве.

REST API

Код, который написан и читается, словно он вовсе не асинхронный (все вызовы друг за другом).

пример из js

const parseAdminsData = async ()=>{
  const token = await getToken();
  const users = await getUsers(token);
  const admins = users.filter(({isAdmin})=>isAdmin);
  return admins;
}

вот тут два асинхронных запроса, но в коде они выглядят просто как вызовы функций. (без колбэков)

Вручную набивать сырые данные нужно только для проверки каких то особых совпадений активностей или граничных, которые могут быть неправильно обработаны логикой агрегации или для явной демонстрации что работает как надо. Тут эксель и не нужен скорей всего будет.
Причем тестовые данные желательно не напрямую в бд забивать а эмулировать отправку их через основное приложение.
А вот для прогонки через эксель можно использовать и реальные данные от пользователей.

Черновая часть бизнес-логики опирается на взаимодействие моделей, которые как правило должны обладать нечто типа CRUD. Зачастую там немало кодописательства, особенно при наличии различных верификаций, поэтому их написание заметно по затраченному времени, а самые изюминки - они чуть раньше (архитектура) и чуть позже (взаимодействие, поведение), но малозаметны именно за счет хорошо подготовленного фундамента в виде оттестированных "кирпичиков".

Если нравятся интересные задачи, то я думаю таковые вы найдете на более нагруженных проектах, где и архитектура приложения гораздо сложнее. Например, где и как хранить данные (реляционное или nosql решение), каким образом масштабировать систему, как и какую часть системы выносить в отдельный сервис и как организовать взаимодействие между сервисами, оптимизация тех же sql запросов, профилирование и нагрузочное тестирование, применение асинхронного подхода. И это только для любого нагруженного проекта, а если при этом довольно интересная предметная область ?!

Не знаю как у вас с английским, но есть такое старое видео https://www.youtube.com/watch?v=vXjVFPosQHw про архитектуру масштабируемых приложений. Там как раз рассказывается про общие принципы. Презентация из этого видео - https://www.slideshare.net/nzakas/scalable-javascr... , в принципе там есть примеры кода, думаю, будет полезна.

Ищите крупную продуктовую компанию, а не аутсорсный бодишоп. Не связывайтесь с гос. сектором и телевидением. Ищите контору с крупным собственным продуктом, бизнес которой построен не на его продаже/внедрении.

1) Ну можно поднимать Vagrant'ом виртуалку и туда все деплоить каким-нибудь ansible'ом
прогонять тесты и после этого удалять виртуалку
тут есть 2 преимущества: весь процесс деплоя описан в ансибл скриптах и он будет рабочим так как будет испльзоваться постоянно, и второй плюс - не нужно ничего откатывать, просто vagrant destroy.
с докером все тоже самое можно организовать
если по богатому - то виртуалки можно не локально запускать а где-то в клауде ( меньше геморроя будет, вагрант не нужен и тд)

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

3) на каждый пул-реквест я бы такие тесты не гонял потому что как показывает практика опять же - они довольно тяжеловесные получаются и занимают прилично времени
есть же стандартные use-case scenarios - раз в день ночной билд, регрессия перед релизом, прогнать разок перед тем как собрались мержить фичу в мастер

вообще тут очень все субъективно
зависит от того как настроенны процессы у вас в кампании, как часто вы деплоите, насколько большое требуется покрытие и тд и тп

Делаете docker-compose файл, в котором поднимаете контейнеры со всеми нужными сервисами (DB, API,..., selenium/что угодно).
Делаете контейнер, который маунтит папку с тестами в себя и запускает их
Тогда тесты будут запускаться грубо говоря одной командой docker-compose up %название_сервиса%
В CI это можно запускать так же (по крайней мере в travis / jenkins)
Про хранение - логичнее всего держать это в отдельной репе, если фронт и разные API находятся в разных репозиториях, это же не тесты фронта.