Spring Boot Spock Autowire

Cześć uczę się pisać testów. Mam kilka pytań.

1. Takie coś testuje się integracyjnie czy jednostkowo ?

    @Transactional(value = "transactionManager")
    public void register(RegisterUser user) {
        if (isUserExist(user)) {
            throw new UserAlreadyExistException();
        }
        userRepository.save(userMapper.toUser(user));
        log.info(String.format("User %s registered!", user.getLogin()));
    }

    private boolean isUserExist(RegisterUser user) {
        return userRepository.findByLoginOrEmail(user.getLogin(), user.getEmail()).isPresent();
    }

2. Czy można użyć autowire bez ładowania całego springa ? (Jakaś inna opcja) tak żeby wytestować jednostkowo metody w serwisie ?
3. Jeżeli mam metodę podobną jak wyżej (chodzi mi o isUserExist) to jak mogę tylko ją wytestować ?

1. A co da ci tu test jednostkowy? Przecież cała logika którą tu masz opiera się na userRepository. Mógłbyś oczywiście go sobie zamockować ale wtedy w zasadzie jedyne co możesz przetestować to że rzuci ci wyjątek jeśli isUserExist zwróci true, nic więcej, bo żadnej innej logiki nie ma. Normalny człowiek odpaliłby bazę in memory i na niej testował, bo dzięki temu testujesz też to repository
2. Nie, zresztą nie bardzo rozumiem jak by to wg ciebie miało wyglądać. Bo niby chcesz żeby spring utworzył ci zalezności, ale z drugiej strony nie chcesz żeby spring startował. Zdecyduj się.
3. Nie możesz i pewnie nie powinieneś skoro to metoda prywatna. Testuje się funkcje systemu a nie metody! Powinieneś mieć takie testy:

• error jeśli rejestrujemy istniejącego użytkownika
• error jak baza się wysypała
• sukces jeśli rejestrujemy nowego użytkownika

To ze pod spodem są jakieś klasy i metody to jest szczegół implementacyjny. Co ci tutaj niby da zejście z testami na poziom serwisu?
Jak sobie zrobisz ładny DSL pod testy i jakieś bazy in memory to potem takie testy piszę się bez żadnych problemów.

@Shalom:
No dobra ale np w serwisie mam tak:

    @Override
    public void test(Koszyk koszyk) {
        coś robi..
        policzCene(koszyk)
        coś robi
    }

    private BigDecimal policzCene(Koszyk koszyk){
        liczy tutaj
    }

No i chciałbym się upewnić i przetestować tylko policzCene jak takie coś dokonać ?

Ad 2 chciałem przetestować niektóre metody jednostkowo i wstrzyknąć Serwis przez to moje pytanie z @Autowire

Testuj funkcje „biznesowe” (czyli to czego oczekuje się po systemie), a nie klasy i metody, tym bardziej prywatne! Testuj co robi system, a nie w jaki sposób.

Hint: najpierw napisz test, potem dopiero kod. Samo się ułoży. Teraz próbujesz dopisać dziwne testy do istniejącego kodu, co jest dramatem z kilku powodów.

No i chciałbym się upewnić i przetestować tylko policzCene jak takie coś dokonać ?

Nie robić. Czemu chcesz cementować implementacje przez jakieś testy szczegółów? Przecież taka metoda w ogóle może nie istnieć! Testuj FUNKCJE SYSTEMU a nie szczegóły implementacyjne!
Zrób np. test Jak dodaje przedmiot o wartości X do koszyka to wartość koszyka wzrasta o X. I cyk:

• tworzysz konfiguracje systemu z przedmiotem A o cenie X do kupienia
• startujesz system
• pobierasz aktualną wartość koszyka
• wysyłasz request który dodaje A do koszyka
• pobierasz wartość koszyka
• sprawdzasz czy nowa wartość koszyka wzrosła o X

Taki test sprawdza czy twoja aplikacja faktycznie działa tak jak powinna. Co wiecej, jak jutro zrobisz refaktor i usuniesz metodę policzCene bo tą logikę przeniesiesz w inne miejsce, to testy nadal będą działać.

Jeśli to liczenie ceny jest na tyle złożone że chcesz je koniecznie jednostkowo testować, to powinno mieć swoją osobną klasę i publiczne metody. I możesz sobie zrobić test jednostkowy na to, ale nie rozumiem gdzie ci potrzebne do tego jakieś Autowire, skoro testujesz ten konkretny obiekt domenowy.

To jeśli chodzi o integracyjne mam poukładane w główce. Kiedy w ogóle powinienem testować jednostkowo , jeżeli serwis testuje integracyjnie?

Idealnie: w ogóle ;)
w praktyce: wtedy kiedy masz faktycznie jakiś dziki algorytm który szybciej jest przetestować dając mu różne wejścia i sprawdzać wyjścia.