테스트는 문서다  테스트는 문서다 - 프로덕션 기능을 설명하는 테스트 코드 문서 - 다양한 테스트 케이스를 통해 프로덕션 코드 이해하도록 도와줌 - 한 사람의 경험을 팀 차원으로 모두 공유 가능  우리는 항상 팀으로 일하기 때문에 좋은 테스트 코드를 문서로 작성해야한다  DisplayName을 섬세하게  @DisplayName("음료 1개 추가하면 주문 목록에 담긴다") // 테스트명을 적어준다 @Test void add(){ CafeKiosk cafeKiosk = new CafeKiosk(); cafeKiosk.add(new Americano()); assertThat(cafeKiosk.getBeverages().get(0).getName()).is..

서론 Test Driven Development 란?- 구현먼저 하는 것이 아니라 테스트를 먼저하고 기능을 구현하는 개발 방법론  1) 실패하는 테스트 작성 2) 테스트 통과 최소한의 코딩 : 통과하기 위해 막 짜도 괜찮 일단 통과만 하도록 짜라3) 구현 코드 개선 , 테스트 통과 유지 : 구현 코드를 개선하면서 품질 향상   본문  1단계 - 빨간불 보기 // 컴파일 에러 방지용 기능 구현 public int calculateTotalPrice(){ return 0;}// 빨간색 불 들어오는 테스트코드@Testvoid calculateTotalPrice(){ CafeKiosk cafeKiosk = new CafeKiosk(); Americano americano = new America..

서론 테스트는 간편하게 해야하고 기계가 알아서 통과 여부를 확인할 수 있게 짜야한다.수동 테스트처럼 일일이 화면 클릭해서 확인하고 감에 의존해서 합격 불합격하는 테스트는 신뢰성이 낮다   이게 괜찮은 테스트 코드인가? @Test void add() { CafeKiosk cafeKiosk = new CafeKiosk(); cafeKiosk.add(new Americano()); System.out.println(" == 담긴 음료수 수 : " + cafeKiosk.getBeverages().size()); System.out.println(" == 담긴 음료수 : " + cafeKiosk.getBeverages().get(0).getName()..

서론  테스트는 왜 필요하니? - 조미료 같은 놈 - 사실 서비스에 직접적인 영향을 주진 않지만 있다면 품질의 안정성을 보장해주고, 좋은 테스트 코드는 유지보수 시간을 단축 시킨다 - 다만 스케줄이 빠듯한 경우 테스트 코드 작성이 매우 귀찮은 작업이 되어버림    본문   이미 수동으로 테스트가 끝난 코드가 있는데 여길 다른 사람이 조금만 수정한 경우가 있다.  근데 이게 이미 테스트 했던 기존 영역을 한 번 침범하니까.. 기존 꺼가 정상적으로 동작하는지 또 또 테스트 해야하는 아주 비생산적인 활동을 하게 된다....  특히 테스트코드 없이 수동으로 하다보면 사람의 실수가 생기고 유지보수가 어려워지는 악순환이 발생한다.  테스트 코드를 작성한다면 ? 1. 빠른 피드백 : 코드만 실행하고 결과만 보면 되니..

서론 요구사항 변경이 생겨서 코드 수정이 발생했다. 이 때 수정할 거를 제대로 수정 못해서 코드 리뷰 때 빠꾸 먹은 게 있어서 까먹지 않게 여기에다가 정리를 하려고 한다. 본문 1) Entity 수정 - Entity의 데이터 타입 수정 - 변수명을 변경된 테이블 속성이랑 일치 시키기 - 정의된 변수 순서 또한 테이블의 순서랑 일치 시키기 테이블에 변경 사항이 생기면 가장 영향을 많이 받는 곳이 엔티티 쪽이다. 특히나 엔티티는 테이블의 속성 전부를 가지고 있어야 하는 곳인데 테이블 속성의 순서 변경이나 타입, 이름 변경이 발생한 경우 무조건 테이블에 맞춰서 테이블의 정의에 따라서 수정이 이루어져야한다. 2) DTO 수정 - 변수명을 변경된 테이블 속성이랑 일치시키기 - 변수 타입과 순서를 테이블과 일치 시..

서론 회사에서 드디어 테스트코드를 작성하는 방침으로 프로젝트를 진행하게 되었다. 전에는 MR하고 프론트랑 합쳐서 테스트를 화면 단에서 버튼 눌러가면서 잘 동작하나 확인하는 느낌으로 결합 테스트를 했지 백엔드 전용으로 코드를 테스트 하지 못해서 통합 테스트랑 단위 테스트랑 별 차이가 없었다. 그저 로컬 환경에서 테스트하냐 데브 환경에서 테스트하냐 라는 차이정도? 그러다 테스트 코드를 도입하게 되었는데 영 감을 못 잡아서 정리해보고자 한다. 테스트 종류 단위 테스트 - 하나의 모듈을 기준 독립적으로 진행되는 가장 작은 단위 테스트 - 하나의 메서드에는 하나의 기능이 들어가듯 하나의 테스트에는 하나의 동작만 테스트하도록 작성 = 가장 작은 단위 테스트니까! 통합 테스트 - 모듈 통합과정에 모듈 간의 호환성 확..

서론 코드 리뷰를 받다가 이런 지적을 받았다. 코드 리뷰 중 수현상 왜 DTO를 사용해서 테이블의 데이터를 받아서 써요? 나는 코드를 보면 엔티티와 DTO폴더가 나누어져 있는건 알고 있었지만, 왜 나눴는지 주의깊게 보지 못했고 또 코드 작성할 때 그런 부분은 생각하지 않아서 이런 실수를 저질렀다. 특징 기본적으로 엔티티와 DTO는 그 존재 이유가 다르기에 설계부터 나눠서 사용을 해야한다. 1. 엔티티 - 데이터베이스의 테이블과 매핑되는 클래스 - 주로 JPA를 사용하여 데이터베이스와 상호작용을 처리 : MyBatis에서도 사용함 - 엔티티는 영속성을 가지며 데이터 베이스 상태를 객체로 표현한다. - 주로 CRUD 작업 수행 시 사용되며 반환값으로도 사용되는 엔티티 클래스 - 보통 테이블의 전 속성에 매핑..