В смысле не то? Я пошел в свой докер-десктоп, и запустил там контейнер nginx заэкспоузив порт 30600:80, после чего вбил в адресную строку хрома host.docker.internal:30600 и получил ожидаемую «Welcome to nginx!». Я чего-то не понял в вопросе?
Если это виртуалка в VirtualBox к примеру, то у нее в настройках сети есть mac-адрес, и он не меняется при перезапусках — в настройках домашнего роутера можно для него прописать конкретный ip в настройках dhcp.
Кстати, а где-нибудь еще кроме Elite полет реализован, как вращение корабля вокруг своей оси, плюс задирание/опускание носа? Везде и всюду космос на колесах, буквально езда вперед-назад и влево-вправо. В Элите прямо чувствовалось отсутствие верха и низа, никакой даже условной плоскости в которой происходит движение. Ничего подобного больше не встречал.
Просто думаю, почему ж у меня в памяти отложилось, что в вебсокете одновременно может быть только одно сообщение? Очевидно что-то же заставило меня так думать…
Насчет сотен не скажу, но сразу несколько вебсокет-соединений могут иметь смысл — одновременно в вебсокете может находиться только одно сообщение, либо «туда», либо «оттуда», поэтому при большой интенсивности может иметь смысл открыть два соединения, одно, например, для интенсивного получения данных, а второе для относительно редкой отправки своих реакций на сервер. А может еще и третье — для пушей сервера других событий. Больше ничего в голову не приходит.
Говоря о вознаграждении, можно отметить, что на уровне компании существует прозрачная система премирования, которая привязана к выполнению личных целей сотрудников.
Если накат liquibase сделан отдельным джарником, который нужно отдельно запускать, то могут быть проблемы, но если он классически часть проекта, то накатится сам точно так же, как на БД развернутую обычным методом.
Это уже зависит от того, что используется в вашем проекте. Если это java+spring boot, в котором вы используете spring-data, то вы можете просто инжектнуть себе в тест бин соответствующего репозитория, и через него заполнить БД. По факту-то тест работает с реальной БД в контейнере, и работать с ней можно ровно так же, как с обычной базой. Testcontainers же это не про заполнение БД, да и вообще не про БД, а про поднять контейнер, а потом удалить его, когда нужда в нем исчезнет. А уж что в этом контейнере будет не суть важно, может кафка, а может и rabbitmq.
При использовании аннотации TestContainers будет создаваться новый docker-container с базой для каждого тестового класса, зачем нам это? Не разумнее ли запустить одну базу для всех тестов (например из общего тестового класса осуществить BeforeAll container.start())?
Рано или поздно — и скорее рано — продукты жизнедеятельности одних тестовых классов начнут мешать другим тестовым классам. Добавим сюда произвольный порядок выполнения тестов и то, что некоторые тесты сознательно могут тестировать некое деструктивное поведение, чреватое возникновением «мусора», и готов вывод — тестовая среда должна быть изолированной. На уровне каждого конкретного теста такая изоляция не эффективна и затратна, значит на уровне тестового класса — что и имеем.
Почему не наполнять тестовую БД данными из какого-нибудь sql-скрипта, а не осуществлять BeforeEach repo.save()? Ведь это во-первых, лишнее взаимодействие с логикой, которое никак не проверяется, я уже молчу что в каждом классе прописать надо не забыть этот сетап..
Посмотрим с точки зрения человека, который вынужден чинить покрасневший тест, который написан не им. Он смотрит в тест, и видит конкретный сетап над которым производятся тестовые действия. Если этот сетап отдельный для каждого теста, то вообще хорошо — с пределах теста ясно что делается, над какими данными делается, и какой ожидается результат. А вот «общее заполнение чем-то сторонним» — это самый большой кошмар, какой только может быть. Один тест починил — и сломал еще пяток, потому что все они не явно связаны через данные.
192.168.31.54 host.docker.internal
192.168.31.54 gateway.docker.internal
Засмеялся.
Читайте в нашей новой книге «НИКАК».
Рано или поздно — и скорее рано — продукты жизнедеятельности одних тестовых классов начнут мешать другим тестовым классам. Добавим сюда произвольный порядок выполнения тестов и то, что некоторые тесты сознательно могут тестировать некое деструктивное поведение, чреватое возникновением «мусора», и готов вывод — тестовая среда должна быть изолированной. На уровне каждого конкретного теста такая изоляция не эффективна и затратна, значит на уровне тестового класса — что и имеем.
Посмотрим с точки зрения человека, который вынужден чинить покрасневший тест, который написан не им. Он смотрит в тест, и видит конкретный сетап над которым производятся тестовые действия. Если этот сетап отдельный для каждого теста, то вообще хорошо — с пределах теста ясно что делается, над какими данными делается, и какой ожидается результат. А вот «общее заполнение чем-то сторонним» — это самый большой кошмар, какой только может быть. Один тест починил — и сломал еще пяток, потому что все они не явно связаны через данные.
DLQ есть и в кролике.