Test integracyjny nie wykrywa braku transakcji/sesji

Mam taki test integracyjny, która sprawdza pobieranie sali z miejscami:

@Test
void halls_are_gotten() {
    //given
    var hall = hallRepository.save(createHall());
    var user = addUser();

    //when
    var responseSpec = webTestClient
            .get()
            .uri(HALL_ADMIN_ENDPOINT)
            .headers(headers -> headers.setBasicAuth(user.getMail(), user.getPassword()))
            .exchange();

    //then
    responseSpec
            .expectStatus()
            .isOk()
            .expectBody()
            .jsonPath("$[0].id").isEqualTo(hall.getId())
            .jsonPath("$[0].seats").value(hasSize(hall.getSeats().size()));
}

Sam test przechodzi, ale po odpaleniu apki i próbie użycia tego endpointa leci

failed to lazily initialize a collection of role: com.cinema.halls.domain.Hall.seats: could not initialize proxy - no Session]

bo na tej metodzie nie ma @Transactional:

public List<Hall> getAllHalls() {
    return hallRepository.findAll();
}

A sama encja wygląda tak:

@Entity
@Getter
@ToString(exclude = "seats")
public class Hall {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    @Schema(accessMode = Schema.AccessMode.READ_ONLY)
    private Long id;

    @ElementCollection
    @CollectionTable(name = "seat")
    private List<Seat> seats;

    protected Hall() {}

    public Hall(List<Seat> seats) {
        this.seats = seats;
    }
}

Test integracyjny powinien wykryć brak tego @Transactional i nie przejść. Oczywiście nie używam @Transactional w testach.

Nofenak napisał(a):

Test integracyjny powinien wykryć brak tego @Transactional i nie przejść. Oczywiście nie używam @Transactional w testach.

Nie. To przecież Spring, tu test integracyjny nic nie znaczy - i tak apka zawsze może się wywalić. Co prawda na pewno da sie ten test tak przerobić, żeby faktycznie wywalił się na braku tego @Transactional, ale nie wiem czy to ma sens - zrobisz mały refaktoring i albo test będzie się wywalać, a apka działać. Albo test będzie działać, a apka nie.

a kod po drodze jak wyglada?

I znowu model na front pchasz i masz

Black007 napisał(a):

I znowu model na front pchasz i masz

Tak, bo ten model jest prosty i nie ma sensu używania dto.

Nofenak napisał(a):

Black007 napisał(a):

I znowu model na front pchasz i masz

Tak, bo ten model jest prosty i nie ma sensu używania dto.

I tak powinieneś mieć poziom abstrakcji pomiędzy domeną i widokiem.

nie ma sensu używania dto - i tu się mylisz.

Riddle napisał(a):

Nofenak napisał(a):

Black007 napisał(a):

I znowu model na front pchasz i masz

Tak, bo ten model jest prosty i nie ma sensu używania dto.

I tak powinieneś mieć poziom abstrakcji pomiędzy domeną i widokiem.

nie ma sensu używania dto - i tu się mylisz.

Dobre praktyki mówią, że domena nie powinna nic widzieć o UI, ale UI jak najbardziej już może wiedzieć coś o domenie.
Domena udostępnia jakiś model domenowy i inni typu REST, apka mobilna i co tam jest jeszcze, powinni się do niego dostosować albo sobie przemapować to na swoje modele, jeśli mają taką potrzebę.
DTO jest spoko jeśli nie chcemy pokazywać jakiś pól, pokazać je w inny sposób albo to jakaś agregacja z kilku obiektów

Model ORM to nie jest cześć domeny.

Żadna "dobra praktyka" nie mówi nic o tym że możesz modele z bazy danych wsadzić na front. Ty próbujesz wrzucić model hibernate do widoku, i to jest straszna lipa.

Nawet nie chodzi o domenę, ale o SOLID.
Zasada jednej odpowiedzialności nie jest tu dla ozdoby, jak widzę patologie, takie jak json zmieszany z entity "to wiem że coś się dzieje".