GraalVM позволяет запускать код быстрее, чем на привычных инструментах OpenJDK. Но как? Aleksandar Prokopec (Oracle Labs) на простых примерах покажет, какие оптимизации используются в GraalVM и как это влияет на производительность. https://habr.com/ru/company/jugru/blog/485024/

Спасибо!

Спецификация с одной стороны, верификация с другой стороны

Для этого есть мутационные тесты, к счастью

Не согласен с последним

а разверни немного

ты считаешь что написание тестов не поможет задизайнить более "тесто-пригодный" код?

Всё зависит от твоего упорства. Можно без редизайна протестировать. Я такое видел: рефлексией в тестах подсовывались данные в final поля класса и потом на этих данных тестировалось

но зачем так делать? если можно было сразу подумать о том, как ты это будешь тестировать и сделать более удобное внедрение зависимостей, например

Не стоит списывать на умысел то, что можно списать на обычный идиотизм

ну и рефлексия в тестах это такое себе.. у тебя тест в итоге гвоздями прибит к текущей реализации, он проверяет ровно то что написали, а не то что обещает класс делать

🤣

Это не значит что это плохой тест, просто не не помог тебе сделать хороший дизайн

ну плохой/хороший сложно в отрыве от примера...

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

Для того, чтобы зафиксировать требования (в идеале - требования ТЗ) к поведению определенного элемента (юнита) системы.
Пользы две основные - 1) при изменении кода будет произведена проверка того, что требования по прежнему выполняются, 2) при изменении требований будет выявлено, что элемент не соответствует новым требованиям

Нормально делай, нормально будет

Я против юнитов. Нужны только модульные тесты.
Во-первых,  юниты надо вечно переписывать, если приложение не мёртво, и уже тут они начинают вредить(и даже идеальный тест превратится в шлак за х переписок)... во-вторых рано или поздно превращаются в формальность ради покрытия.

Модульные,  меняются сильно реже. Тестируют выделенную функциональность. Могут выступать как документация.

Юнит как документация, это сказка в крупных проектах. Написать юнит хорошо , это искусство на уровень выше чем писать код.
Если вспомните юниты: формируем  какой-то внутренний класс , заполняем кидаем в метод в котором все замокано, и возвращено тоже любое значение.
Не тест , а иллюзия теста.

Юнитами только утилитные классы хорошо покрывать: свои коллекции,  компораторы и т.д.

а давно ли модульные переписывать не требуется? если написано в формате "вызвал и не пятисотнуло, а чем ответило все равно", то соглашусь. но это уже профанация, а не тест.
в то же время это уже покрывает больше логики и для поддержания актуальности требует большего погружения в проект

Переписывать требуется. Но вероятность  бизнес изменения поведения ендпоинта сильно меньше , чем вероятность изменения кода(для неважно какой цели рефакторинг/добавление фичи).

любопытное разделение на юнит и модульные тесты... может быть вы имеете ввиду тесты с моками и тесты без моков?