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