Жесть в такие тесты потом смотреть - заглядываешь, а там куча конфигов своих, что-то куда-то инжектится, откуда-то берётся. По идее тесты должны быть живой документацией к коду. Запутался в коде, глянул в тесты, запустил, подебажил и въехал. А тут отдельный мир со своим контекстом и конфигами.
Spring сам по себе такой. В большинстве других фреймворках (на других языках) просто устанавливаешь библиотеку и юзаешь. А тут нужно конфиг файл запилить, содержимое которого только гуглежом можно получить, далее бины бины и бины, аннотации аннотации и аннотации.
далеко не всегда по тестам понимаешь что тест делает. Тем более обычно новичка (ну меня точно) поставили на испыталку писать тесты к 30 классам довольно сложным с Spark логикой к которой просто не было тестов. Да и тесты такая штука что можно написать 2+2 = 5 и всё будет проходить ещё так написать что никто не поймёт тесты это же ты сам ручками вводишь что ожидаешь.
по моему это самый худший вариант. тут без гугления никак не разобраться. спринг и так вынуждает изучать его тонкости так теперь и на каждую автоконфигурацию нужно гуглить.
ребята поскажите пожалуйста если мы используем @SpringBootTest и в нем используем @TestConfiguration то если ли способ сказать спрингу чтобы бины из тестовой конфигуарции были всегда в приоритете над обычной конфигурацией? без эксплиситного указания @Primary?
Лучше бы показали как правильно тестировать на разных слоях, (как, куда и для чего писать юнит, интеграционные), а не вот это все, и кто вообще зависимости от классов делает ?
дело в том что ответ кроется не в какой то специфике спринга или его тестирования. ответ кроется в пирамиде тестирования (и реалиях в которых пишется код, например если времени мало а хочется побольше покрытия то будут использоваться e2e тесты с максимально "настоящей" интеграцией). В остальных случаях нужно выбирать золотую середину между количеством тестов (а как следствие качеством покрытия) и затраченным временем (в тч временем на поддержку)
Жесть в такие тесты потом смотреть - заглядываешь, а там куча конфигов своих, что-то куда-то инжектится, откуда-то берётся. По идее тесты должны быть живой документацией к коду. Запутался в коде, глянул в тесты, запустил, подебажил и въехал. А тут отдельный мир со своим контекстом и конфигами.
Spring сам по себе такой. В большинстве других фреймворках (на других языках) просто устанавливаешь библиотеку и юзаешь. А тут нужно конфиг файл запилить, содержимое которого только гуглежом можно получить, далее бины бины и бины, аннотации аннотации и аннотации.
далеко не всегда по тестам понимаешь что тест делает. Тем более обычно новичка (ну меня точно) поставили на испыталку писать тесты к 30 классам довольно сложным с Spark логикой к которой просто не было тестов. Да и тесты такая штука что можно написать 2+2 = 5 и всё будет проходить ещё так написать что никто не поймёт тесты это же ты сам ручками вводишь что ожидаешь.
5/5 для QA, который не хочет читать спринговую документацию
@AutoConfigureTestDatabase(connection = EmbeddedDatabaseConnection.H2) и можно без TestContainers в некоторых простых случаях
по моему это самый худший вариант. тут без гугления никак не разобраться. спринг и так вынуждает изучать его тонкости так теперь и на каждую автоконфигурацию нужно гуглить.
Есть особенности синтаксиса SQL. И то что работает на проде (например Оракле) может не работать в H2
Вот бы час отлаживать обвязку к тестам 😆
Когда Кирилл без Жени все так спокойно, потихоньку xD
ребята поскажите пожалуйста если мы используем @SpringBootTest и в нем используем @TestConfiguration то если ли способ сказать спрингу чтобы бины из тестовой конфигуарции были всегда в приоритете над обычной конфигурацией? без эксплиситного указания @Primary?
Господины критики, вам это не то и то не это. Ну сделайте лучше и выложите в общий доступ. Кирилл, спасибо за материал.
Зачем сужать скоуп SpringBootTest если тесты всего приложения будут в этом скоупе, а контекст только один для всех тестов
Лучше бы показали как правильно тестировать на разных слоях, (как, куда и для чего писать юнит, интеграционные), а не вот это все, и кто вообще зависимости от классов делает ?
есть ли видео которое обьясняеет то что вы написали?
дело в том что ответ кроется не в какой то специфике спринга или его тестирования. ответ кроется в пирамиде тестирования (и реалиях в которых пишется код, например если времени мало а хочется побольше покрытия то будут использоваться e2e тесты с максимально "настоящей" интеграцией). В остальных случаях нужно выбирать золотую середину между количеством тестов (а как следствие качеством покрытия) и затраченным временем (в тч временем на поддержку)
можно ссылку на этот код?
github.com/lavcraft/spring-boot-curse
Поучись у Борисова обьяснять.
Попробуем использовать аннотацию SpringBootTest. А пишет SpringBootApplication. Сидишь и думаешь слушать дальше или нет