Здравствуйте, bzig, Вы писали:

B>Интеграционные тесты должны зависеть даже не от публичных контрактов, а от точек доступа, типа порты и урлы, и уж совершенно точно не от кишок.

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

Я говорю о тестах, где компонент проверяется отдельно. Я бы скорее назвал это юниттестом, но нынче народ чаще называет юниттестами тесты для методов и классов, а это тесты для всего сервиса, но без запуска всей REST API системы, без базы данных и т.д. Вместо базы данных подсовываются простые in-memory коллекции, реализующие тот же интерфейс, что и база. Вместо точек доступа REST API мы дергаем методы высокоуровневой бизнес-логики, т.е. по сути почти то же самое, только минуя этап десериализации параметров и роутинга — те части проверяются уже когда мы запускаем все вместе.

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

AK>>Ну отчасти да. Везде, где надо, выставлены интерфейсы, но народ иногда ставит ссылку на реализацию,
B>package private на реализацию + public static методы для создания реализации с необходимыми свойствами.

"Вас много, а я одна!"
Все так, но проект большой, а людей, придирчивых к хорошему внутреннему дизайну компонент, не очень много. Я улучшаю некоторые части по мере соприкосновения с тем кодом, но по большей части приходится иметь дело с тем, что уже есть.

Здравствуйте, bzig, Вы писали:

B>Интеграционные тесты должны зависеть даже не от публичных контрактов, а от точек доступа, типа порты и урлы, и уж совершенно точно не от кишок.

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

Я говорю о тестах, где компонент проверяется отдельно. Я бы скорее назвал это юниттестом, но нынче народ чаще называет юниттестами тесты для методов и классов. А у меня там тесты для всего сервиса, но без запуска всей REST API системы, без базы данных и т.д. Вместо базы данных подсовываются простые in-memory коллекции, реализующие тот же интерфейс, что и база. Вместо точек доступа REST API мы дергаем методы высокоуровневой бизнес-логики, т.е. по сути почти то же самое, только минуя этап десериализации параметров и роутинга — те части проверяются уже когда мы запускаем все вместе.

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

AK>>Ну отчасти да. Везде, где надо, выставлены интерфейсы, но народ иногда ставит ссылку на реализацию,
B>package private на реализацию + public static методы для создания реализации с необходимыми свойствами.

"Вас много, а я одна!"
Все так, но проект большой, а людей, придирчивых к хорошему внутреннему дизайну компонент, не очень много. Я улучшаю некоторые части по мере соприкосновения с тем кодом, но по большей части приходится иметь дело с тем, что уже есть.