Ну понятно, что ещё надо тонкости понять. Но это как после велосипеда в машину

До Spring Boot-а, в чистом Spring Framework нужно было кучу  xml-файлов описывать и кучу зависимостей подключать и настраивать. Spring Boot это все скрывает на  начальном этапе. Но потом копаться глубже все равно придется.

Я тебе ещё скажу, что современная Андроид-разрабртка сильно завязана на чистой архитектуре. Тебе в любом случае нужно нормально штудировать основы языка

Когда я начинал, то мой хелло ворлд на спринг несколько десятков файлов содержал.

Я скакала от мавена. Сама ручками зависимости ставила. Веб подключала

ок, спасибо

Что конкретно беспокоит? Этот объект ни где больше не виден. Какая разница, что с ним?

muh memory

Я на столько тонко не знаю, но скорее всего он помечается как готовый к утилизации и когда GC придет, он его сотрет.

А нет не так

Написано следующее:
By design в первый проход строится дерево инстансов, во второй проход происходит выполнение тестов, поэтом до конца выполненич всех тестов раннер держит сильные ссылки на все ресурсы, а значит они не могут быть очищены GC. Поэтому, когда вы выполняете большой файл или задействуете внешние, временные или ограниченные ресурсы, освобождение их - ваша ответственность. Это можно сделать явно присвоив null в объект в методе tearDown().

Не знаю, на сколько это актуально, версия JUnit не указана, сейчас погуглю еще.

машину, которая самосвал, а вам надо было всего то ящик один перевезти на соседнию улицу

Нашел, это из офиц FAQ JUnit4. Про 5 не известно, вроде не изменилось ничего.

а вы не знали то что вы ВООБЩЕ никак не можете повлияеть на сборку обьектов и не важно тест это или нет

А я и не хотел повлиять на сборку

Я хотел сразу удалить обьект

мимо GC?

типа того