Илья Чубаров

На сколько я вижу это инфраструктурный код - поэтому проще его тестировать функциональными тестами (которые в папке Laravel называются Feature)
1) Решается функциональным тестом, будет использоваться тот который укажете - подойдет просто оперативная память
Имеется в виду - что вы просто отправляете запрос и ждете определенный результат
2) Можно задать в тесте - а лучше в файле окружение env.testing
3) Почему у вас ищет метод environment в Container без контекста сказать сложно, этот метод в классе Application

Начальный вариант это нормализованные таблицы
Например:
- Таблица car_make
- Таблица car_model
Где в car_model есть поле car_make_id, это внешний ключ и он уже имеет индекс.
Далее вы выводите список(form select) из вашей таблицы или поиском(пользователь вводить начало названия) по таблице в car_make
Пользователь выбирает определенную марку, в таблице car_model вы можете по id выдать список всех моделей.
Что касательно дат, реализовать можно по разному.
В вашем файле у вас фиксированный диапазон и его можно добавить в таблицу car_model двумя колонками.
Если модель может иметь несколько диапазонов выпуска, можно это хранить в отдельной таблице, где поля будут такие:
car_model_id, start_date, finish_date
Соответственно при выборе в интерфейсе определенной модели, мы можем выбрать список с диапазонами дат.
Правильных ответов тут нет, и зависит от целей, какие могут быть перспективы и так далее.

Например в одном моем проекте был похожий функционал. И использование такой формы, показало что разные марки и модели могут по-разному вводиться пользователями, для примера есть лада и ваз.
И пользователь будет вводить всегда свою версию.
В таком случае для каждой модели и марки пришлось заводить отдельные таблицы - словари.
Где версия пользователя, хранила ссылку на стандартную версию.
То есть у нас была Лада.
Соответственно:
ВАЗ = Лада
Лада = Лада
Kalina - Калина