Oryginał

Próbuję pobrać w teście aplikacji Spring Boot (v2.3.8) tylko nazwane elementy w podstawowym kontekście aplikacji Spring. Bardziej konkretnie, chcę pobrać w teście kontekst aplikacji Spring, który dostosowuje się, co najmniej, rejestrowanie, pobieranie zewnętrznych właściwości, sprawdzenie (poprzez API do sprawdzania Java) i @Value-połączenie, ale bez MVC, JPA danych, itp. W rzeczywistości, chcę przetestować za pomocą interfejsu z adnotacjami ograniczeń (np. @NotBlank), a @Service to korzysta tylko z lokalnego systemu plików (bez MVC, JPA danych lub innego "cięcia" testu pobrania Spring) i ma jeden element danych, wypełniony przez @Value.

Ja bezskutecznie próbowałem wiele komentarzy (i niektóre z przypisywanych im atrybutów) w różnych kombinacjach-różnych podzbiorach: np. @SpringBootTest, @Configuration, @ContextConfiguration, @TestConfiguration, @TypeExcludeFilters itp., Np.:

@Validated
public interface SomeService {
    String someMethod (@NotBlank String someParam);
}
...
@Service
public class SomeServiceImpl implements SomeService {

    @Value("${some.value}")
    private String someValue;

    @Override
    public String someMethod(String someParam) {
        // do something with local file-system,
        // with someValue in hand, and
        // knowing someParam not blank
    }
}
...
@SpringBootTest(classes={SomeServiceImpl.class},webEnvironment=WebEnvironment.NONE)
class SomeServiceTests {

    @Autowired
    private SomeService someService;

    @Test
    void throwConstraintViolationException_whenSomeParamNil() {
        assertThrows(
            ConstraintViolationException.class,
            ()->someService.someMethod(new String()));
    }
    ...
}

W tym przykładzie atrybut classes od @SpringBootTest ładuje to klasa, ale ukrywa wszystkie podstawy (prowadzenie magazynu, kontrola itp.), Które ja również szukam.

Następujący fragment z książki Craiga Уоллса "Sprężynowy butów w akcji" wydaje się właśnie to, czego szukam, ale jego podstawowym narzędziem (@SpringApplicationConfiguration) teraz jest nieaktualny (i go oficjalnie zalecana wymiana - @SpringBootTest - nie zachowuje się tak samo, przynajmniej w odniesieniu do atrybutu classes):

Chociaż @ContextConfiguration radzi sobie z pobieraniem kontekst aplikacji Spring, że nie pobiera go z pełnym obciążeniem Spring...SpringApplication nie tylko pobiera kontekst aplikacji, ale także pozwala prowadzić dziennik, pobierać zewnętrzne właściwości (application.properties (właściwości) lub application.yml) i inne funkcje Spring Boot. Jeśli używasz @ContextConfiguration, nie dostaniesz tych funkcji. Aby przywrócić te funkcje w swoje imprezy integracyjne, testy, można wymienić @ContextConfiguration na @SpringApplicationConfiguration Spring Boot:

@RunWith(SpringJUnit4ClassRunner.class)
@SpringApplicationConfiguration(classes=AddressBookConfiguration.class)
public class AddressServiceTests {
...
}

Tam dostaje "pełną obsługę wiosennej pobrania", ale dodaje tylko klasa ( -@Service) cytuje (nie każdy @Component, @Controlleri @Repository jego włości).

Jak to zrobić dzisiaj, bez starszych @SpringApplicationConfiguration?

Zaktualizować

Początkowo oświadczył, że mój (nie Craiga Уоллса) przykład (a mianowicie @SpringBootTest(classes={SomeServiceImpl.class},webEnvironment=WebEnvironment.NONE)choć pobrał klasa, ukrył wszystkie podstawy kontekstu aplikacji, który zazwyczaj jest ładowany podczas uruchamiania Spring. W trakcie dalszych eksperymentów okazało się, że to stwierdzenie było niedokładne, ponieważ nie wszystkie, a tylko niektóre podstawy ukryte, a mianowicie sprawdzanie (implementacja API do sprawdzania Java). Innymi słowy, rejestrowanie, uruchamianie zewnętrznych właściwości i podłączenie @Value naprawdę pobrane/skonfigurowane. Myślę, że musi być zagubiony we wszystkich moich licznych logistyce/próbach.