Концепция большинства тестов достаточно простая: вызвал метод, получил результат, проверил результат.
В assertThat() можно передать только один параметр - результат, который будем проверять. Это достаточно интуитивно. Я пока что не встречал разработчиков, у которых с этим бы возникли проблемы.
assertEquals() из JUnit противоречит концепции "чистого кода" - два параметра одинакового типа, которые легко перепутать местами, и код скомпилируется. В большинстве случаев это не проблема, но иногда мешает: читать логи упавшего теста в CI-пайплайне (особенно когда локально тест проходит) или на code review, когда один разработчик поучает другого правильно использовать assertEquals.
Я предпочитаю проверять интеграционным тестом (с Testcontainers, например). Потом на тестовом стенде, который не жалко, и который в случае чего можно перераскатить с нуля.
Комментарий был больше про то, что "безопасные", на первый взгляд, примеры и решения могут на самом деле таить в себе огромный риск, если не понимать, что происходит под капотом.
В статье есть деструктивные примеры, которые лучше не применять на практике. В частности, "проверь свой запрос".
Всё, что вы делаете в БД, остаётся в БД и влияет на её прямым образом.
Нельзя просто так начать транзакцию, откатить ее и сделать вид, что ничего не было. База по-честному будет выполнять ваш запрос, используя backend процесс, потребляя CPU/диск и генерируя WAL.
Бездумно используя подход с begin/rollback, можно выстрелить себе в ногу и на время положить кластер БД.
Я из тех, кто живёт в Ярославле и прошёл и Тензор, и Диасофт, и Аквелон. Дольше всего задержался в Тензоре - 2 года. Куда бы мог вернуться - Аквелон. Диасофт стал хорошей площадкой для старта, но туда больше ни ногой..
У меня нет готового примера/кусочка кода, который можно было бы показать, но себя в Kubernetes/OpenShift мы используем следующий подход: 1) в deployment добавляем соответствующий init-container, в котором дожидаемся доступности БД (цикл, ограниченный по времени и числу итераций); 2) в readiness пробе проверяем доступность БД (select 1, например).
Сначала стартует init-контейнер и проверяет доступна ли БД, если нет то уходит в ожидание на какое-то время, после чего снова повторяет проверку. И так несколько раз (все параметры настраиваются).
Затем уже приложение у себя в readiness пробе проверяет доступность БД (перестраховка по сути, можно отказаться от этого).
На самом деле здесь нет правильного ответа. И категорично что-то утверждать будет неправильно. Как и всегда, всё зависит от вашей специфики и нагрузки.
Если у вас большая нагруженная БД, то тащить её в контейнер не очень разумно.
Если у вас микросервисы и вам требуется небольшая БД на 5-10 TPS, то почему нет?
Очень удобная позиция эффективного менеджера — не знать, сколько часов работают люди.
На самом деле всё просто — с высокой долей вероятности люди вджобывают по 60 часов в неделю, а то и больше.
За идею, опционы и средней паршивости ЗП.
Не всегда и везде нужно только уметь писать и отлаживать код.
Но список вопросов мне понравился. Он охватывает много областей и хорошо скажется на кругозоре.
К CAP-теореме ещё стоит добавить BASE.
И обязательно контейнеризацию/Docker и оркестрацию/Kubernetes.
Во всех таких статьях почему-то не говорят об экономии компаний от перехода на удалёнку: не нужны рабочие места, печеньки, кофе и прочее. Экономия получается огромная.
Выглядит как чья-то курсовая работа средней паршивости...
Первое, что бросилось в глаза, это некорректное моделирование отношения трек — исполнитель. У трека может быть много исполнителей.
Про порядковый номер трека уже написали выше. А ещё альбом может быть двухдисковым.
Пароль с ограничением в 20 символов — это зашквар. Хранить, надеюсь, будете в виде хэша с солью?
Жанров может быть много.
P.S. Классной фичей была бы возможность не терять льготные подписки. Поясню на примере Яндекс.Плюса: есть человек, который платит за семейную подписку каждый месяц. Он покупает Яндекс.Станцию и получает ещё полгода индивидуальной подписки. Чтобы этот льготный период не сгорел, его можно привязать к аккаунту и заморозить, либо конвертировать в семейную подписку.
Концепция большинства тестов достаточно простая: вызвал метод, получил результат, проверил результат.
В assertThat() можно передать только один параметр - результат, который будем проверять. Это достаточно интуитивно. Я пока что не встречал разработчиков, у которых с этим бы возникли проблемы.
assertEquals() из JUnit противоречит концепции "чистого кода" - два параметра одинакового типа, которые легко перепутать местами, и код скомпилируется. В большинстве случаев это не проблема, но иногда мешает: читать логи упавшего теста в CI-пайплайне (особенно когда локально тест проходит) или на code review, когда один разработчик поучает другого правильно использовать assertEquals.
Я предпочитаю проверять интеграционным тестом (с Testcontainers, например). Потом на тестовом стенде, который не жалко, и который в случае чего можно перераскатить с нуля.
Комментарий был больше про то, что "безопасные", на первый взгляд, примеры и решения могут на самом деле таить в себе огромный риск, если не понимать, что происходит под капотом.
Да, конечно.
В статье есть деструктивные примеры, которые лучше не применять на практике. В частности, "проверь свой запрос".
Всё, что вы делаете в БД, остаётся в БД и влияет на её прямым образом.
Нельзя просто так начать транзакцию, откатить ее и сделать вид, что ничего не было. База по-честному будет выполнять ваш запрос, используя backend процесс, потребляя CPU/диск и генерируя WAL.
Бездумно используя подход с begin/rollback, можно выстрелить себе в ногу и на время положить кластер БД.
Не понял про одну ноду для OpenShift. CRC чем не устраивает? https://developers.redhat.com/products/codeready-containers/overview
Я из тех, кто живёт в Ярославле и прошёл и Тензор, и Диасофт, и Аквелон. Дольше всего задержался в Тензоре - 2 года. Куда бы мог вернуться - Аквелон. Диасофт стал хорошей площадкой для старта, но туда больше ни ногой..
Согласен, что такой подход получается многословным, но он наглядный. Для учебных целей подходит гораздо лучше.
У меня нет готового примера/кусочка кода, который можно было бы показать, но себя в Kubernetes/OpenShift мы используем следующий подход:
1) в deployment добавляем соответствующий init-container, в котором дожидаемся доступности БД (цикл, ограниченный по времени и числу итераций);
2) в readiness пробе проверяем доступность БД (select 1, например).
Сначала стартует init-контейнер и проверяет доступна ли БД, если нет то уходит в ожидание на какое-то время, после чего снова повторяет проверку. И так несколько раз (все параметры настраиваются).
Затем уже приложение у себя в readiness пробе проверяет доступность БД (перестраховка по сути, можно отказаться от этого).
@Hivemaster
На самом деле здесь нет правильного ответа. И категорично что-то утверждать будет неправильно. Как и всегда, всё зависит от вашей специфики и нагрузки.
Если у вас большая нагруженная БД, то тащить её в контейнер не очень разумно.
Если у вас микросервисы и вам требуется небольшая БД на 5-10 TPS, то почему нет?
Алексей, подскажите, есть ли официальный докер-образ для вашего экспортера на docker hub'е?
Подготовил небольшой пример для локального запуска с docker-compose. Возможно, кому-то пригодится.
Это какой-то новый персонаж?
Если берётесь за перевод, то хоть проверьте гендер автора одной из лучших книг для подготовки к собеседованию :)
Очень удобная позиция эффективного менеджера — не знать, сколько часов работают люди.
На самом деле всё просто — с высокой долей вероятности люди вджобывают по 60 часов в неделю, а то и больше.
За идею, опционы и средней паршивости ЗП.
Рядом с вопросом про TreeMap добавьте ещё вопрос про бинарное дерево поиска.
Ну и понимание того, как дерево строится, тоже будет полезным.
Но список вопросов мне понравился. Он охватывает много областей и хорошо скажется на кругозоре.
К CAP-теореме ещё стоит добавить BASE.
И обязательно контейнеризацию/Docker и оркестрацию/Kubernetes.
WAL-G бы и Одиссея туда
Зачем? Человеку, который попал в FAANG, это не нужно. Риски и юридические последствия куда больше, нежели мнимая выгода.
Во всех таких статьях почему-то не говорят об экономии компаний от перехода на удалёнку: не нужны рабочие места, печеньки, кофе и прочее. Экономия получается огромная.
Выглядит как чья-то курсовая работа средней паршивости...
P.S. Классной фичей была бы возможность не терять льготные подписки. Поясню на примере Яндекс.Плюса: есть человек, который платит за семейную подписку каждый месяц. Он покупает Яндекс.Станцию и получает ещё полгода индивидуальной подписки. Чтобы этот льготный период не сгорел, его можно привязать к аккаунту и заморозить, либо конвертировать в семейную подписку.