분류 전체보기
-
테스트가 너무 크고 복잡하면 로직을 다시 돌아볼 필요가 있다Today I Learned 2022. 11. 4. 23:55
게시글 상세 페이지 조회 REST API 요청 시 백엔드 요청을 처리할 Controller와 테스트 코드를 작성하고 있었다. 홀맨님이 도장을 돌아보는 동안 내가 작성하고 있던 소스코드를 확인하셨고, 소스코드에 문제가 있음을 확인할 수 있었다. 다음은 내가 작성하고 있던 게시물 목록을 조회하는 Controller의 요청을 처리하는 과정을 검증하는 테스트 코드이다. 테스트 코드를 작성할 때에도 이 영역이 어떤 동작을 테스트하려는 영역인지 중간중간 멈칫하는 느낌이 있었다. 일단 기능을 완성시켜야 한다는 생각에 작업을 무리해서 진행했는데, 다시 살펴보니 테스트 코드를 읽는 것만으로 어떤 테스트를 하려는 것인지 나도 이해하기 어려웠다. 다음은 테스트 코드를 통해 검증하는 Controller의 로직이다. 이 로직의..
-
스프린트 주간 2주차 중간점검Today I Learned 2022. 11. 3. 22:54
스프린트 2주차 주간의 중간 분기점을 맞이한 기념으로 중간 점검을 수행했다. 주간 목표, 스토리 포인트 사용량, 지금까지 수행한 작업 내역, 느낀 점에 대해 정리했다. 주간 목표 스프린트 2주차 주간 동안 기본적으로 달성하고자 하는 목표는 다음과 같다. 운동 모집 게시글 목록 조회 구현 운동 모집 게시글 상세 목록 조회 구현 참가자 관점: 인원이 부족한 포지션에 등록 신청 가능 글 작성자 관점: 신청 목록을 확인해 신청자의 신청을 수락하거나 거절 가능 사용 스토리 포인트 및 작업 내역 1 스토리 포인트는 1 뽀모도로를 기준으로 했다. (40분) 요일 사용 스토리 포인트 이행한 작업 화 7 - 운동 모집 게시글 목록 조회에 사용되는 모델에 데이터 추가 (다른 모델에 독립적인 데이터들) - 프론트엔드 프로세..
-
양방향 연관관계를 갖는 객체를 테스트하는 어려움Today I Learned 2022. 11. 2. 23:59
게시글 목록과 관련된 백엔드 구조를 작성하는 과정에서 먼저 구성한 모델들을 Controller가 Service로부터 데이터를 전달받았을 때 DTO를 정상적으로 반환하는 과정을 수행하는지 검증하는 테스트를 작성하고 있었다. 테스트 코드를 작성하면서 동작 검증에 사용할 테스트 데이터들을 정의하던 중, 양방향 연관관계를 갖는 Entity 인스턴스를 생성자로 정의해 마련하는 과정이 너무 어렵게 느껴졌다. 기록해놓는 것을 잊은 관계로 다음의 예시 코드들을 통해 문제 상황을 살펴보도록 하자. 다음의 코드는 특정 사용자의 id를 받아 게시글을 찾는 Service의 메서드를 호출해 결과를 DTO로 반환하는 Controller의 메서드이다. 다음의 사용자, 게시글 Entity 객체들을 테스트에 활용하려 했다. 사용자와 ..
-
POST 요청으로 연관관계를 갖는 객체들의 데이터 생성하기Today I Learned 2022. 11. 1. 23:53
객체 간 연관관계가 존재하는 객체들의 데이터를 한 번에 생성해 저장해야 하는 경우가 있다. 가령 게시글을 작성한다고 할 때, 글과 함께 사진 여러 장을 첨부해 등록하는 경우가 있다. JPA 환경 하에서 이를 구현하고자 한다면 사진 객체 여럿이 게시글 하나를 참조하는 형태가 될 것이다. 나중에 언젠가는 짚고 넘어가야 할 부분이므로 미리 연습해보는 차원에서 POST 요청을 통해 연관관계를 갖는 객체들을 생성해야 하는 순서를 정리했다. 유저 객체를 생성하면서 생성된 유저 객체가 작성자인 게시글들을 동시에 생성하는 경우를 생각해보자. (예시가 이해가 가지 않는다면 유저를 게시글에, 게시글을 이미지에 매핑해보자.) 다음의 테이블들 중 PERSON 테이블에 새로운 사용자를 추가하고, 생성된 사용자 객체를 참조하는 ..
-
@OneToMany와 @ManyToOne으로 Entity 객체가 서로를 볼 수 있게 하기카테고리 없음 2022. 10. 31. 20:54
이틀 전에 til로 작성했던 JPA 환경 하에서 @ManyToMany 관계를 갖는 모델 정의를 지양하게 됨에 따라 객체 간의 관계를 나타내기 위해 간단하게만 살펴보았던 @OneToMany, @ManyToOne 사용법을 다시 살펴보게 되었다. @OneToMany와 @ManyToOne은 Entity 객체들끼리 서로의 개별 id를 통해 서로의 인스턴스를 참조할 수 있게 하는 어노테이션이다. 한 쪽 객체에서 @OneToMany나 @ManyToOne 어노테이션만을 부여하여 한쪽에서만 반대편을 참조할 수 있는 단방향 참조가 있고, 두 객체가 @OneToMany와 @ManyToOne으로 서로를 바라볼 수 있는 양방향 참조가 있다. @ManyToOne (단방향) @ManyToOne이 선언되는 Entity 객체 여럿이 ..
-
메가테라 웹 개발자 과정 18주차 주간 회고주간 회고 2022. 10. 31. 17:28
포트폴리오 기획이 수요일을 기점으로 일차적으로 마무리된 뒤, 한 주 동안 이행할 작업량을 프로젝트 매니저 역할을 맡고 계신 노아 트레이너님과 함께 선정하고 집중적으로 구현을 진행하는 첫 스프린트 주간을 진행했다. 스프린트 주간에 있었던 전반적인 이슈들을 분석해 다음 스프린트 주간에 더 나은 방식을 가져가기 위해 어떻게 해야 할 것인지 돌아본다. 1주차 스프린트 주간 작업 목표 및 성과 분석 이번 주차에는 메인 화면에서 각 기능으로 이동할 수 있는 링크를 만들고, 운동 모집 게시글 리스트와 상세 정보의 일부분을 구현할 예정이었다. 운동 모집 게시글 목록 운동 모집 게시글 상세 정보 운동 모집 게시글 상세 정보 컴포넌트 (사용자 신청 시) 결론부터 이야기하면 목표한 스토리 포인트만큼의 작업량을 채우지 못했다..
-
모델 구조 설계는 데이터베이스 설계가 아닌 객체 설계 먼저Today I Learned 2022. 10. 30. 23:57
모델 구조의 확장 시도 어제 구현한 MVP를 기반으로 기능에 보여질 내용을 확장하기 위해 최초로 작성한 모델을 확장하기 시작했다. MVP는 게시글 목록만을 확인할 수 있는 아주 단순한 모양으로, 모델 역시 최소한의 객체만으로 이루어져 있었다. '게시글' 모델, '사용자' 모델이 존재했고, 게시글 모델은 id와 글 내용, 게시글에 등록된 사용자 리스트, 사용자 모델은 id와 이름, 사용자가 등록되어 있는 게시글 리스트만으로 이루어져 있었다. MVP의 확장은 두 단계에 걸쳐서 하려 했다. 먼저 사용자, 게시글 모델 사이에 '운동 포지션' 모델을 추가할 계획이었다. 여러 포지션들이 게시글 하나에 속하는 구조를, 그리고 각 포지션에는 여러 명의 사용자가 속하고, 각 사용자도 여러 개의 포지션을 갖는 양방향으로 ..
-
양방향 @ManyToMany 관계를 갖는 모델을 정의하고 데이터 가져오기Today I Learned 2022. 10. 29. 22:51
어제 도장에서 결국 모델 정의를 마무리하지 못하고 집에 돌아왔다. 이렇게 줄이고 줄인 최소한의 모델에서도 도대체 어느 부분이 어려웠다는 말인가? 게시글 목록과 상세 게시글을 구현하기 위한 데이터를 가져오기 위해 왼쪽 사진과 같이 백엔드 서버에서 가져와야 하는 데이터들을 구성했다. 이때 게시글과 사용자의 관계는 게시글에 여러 명의 사용자가 포함이 될 수 있고, 반대로 사용자 역시 자신이 참가하는 여러 개의 게시글을 알 수 있어야 하는 다대 다로 서로를 양방향으로 알 수 있어야 하는 구조였다. 이 구조를 지금 알고 있던 내용만으로는 백엔드에서 정의하기가 쉽지 않았다. 관계형 데이터베이스에서 테이블 간의 관계를 나타내기 위한 OneToOne, OneToMany, ManyToOne, ManyToMany 관계 중..