서비스 레이어에서 테스트를 작성하다 private 메서드 테스트의 범위는 어디까지가 적당할까 라는 생각이 들었다. OKKYCon TDD 레퍼런스에서 구현을 테스트하지말고 기능을 테스트 해야한다는 발표를 봤던 것이 생각나서 의문이 들었다. Junit에서 private 메서드를 테스트 할 때 Reflection으로 해당 메서드를 받아와서 실행시킨 결과를 테스트하는 코드를 작성하는데 문제는 이 멤버 메서드를 가진 Service클래스 구현체가 다른 것으로 바뀐다면 바뀐 구현체의 public 메서드에서 별도로 추출한 private 메서드가 생길 것이고 기존의 사용하던 구현체의 private 메서드와 이름과 파라미터가 같지 않으면 테스트가 깨질 것이다. 코드를 통해 예시를 보자면 TestService라는 인터페이스..

개발중에 JPA를 사용하는 의미에 대한 원론적인 깨달음을 다시 얻었다. 기존의 JdbcTemplate이나 잠깐 사용해본 myBatis를 사용할 때 그저 쿼리를 작성하여 데이터베이스라는 서버에서 외부세계를 변화 시키는 용도로만 사용한다는 인식이 강하게 남아있어서 그런지 JPA는 객체지향 스타일로 개발하기 위해 사용는 ORM이라는걸 잊고 있었나보다. 다시 자각한 것에 비해 거창한 상황을 겪은 것은 아니지만 Service단에서 Repository로 특정 엔티티의 값을 없애야 하는 상황이 있었는데 그저 delete로 지우려고하니 violation이라고 친절히 알려주었다. 그래서 "아 지우려고하는 엔티티를 참조하는 다른 엔티티가 있어서 이러는거네"라고 생각이 들면서 JPA는 객체지향 스타일로 개발하는 것이니 관련..

Spring에서 JpaRepository를 확장해서 사용하는 경우 제공되는 기본 메서드 외에 필요한 동작들은 직접 쿼리를 작성해서 메서드를 선언하는데 보통 선언시 메서드의 인자에 @Param 애너테이션을 붙여 네임드 쿼리로 String의 쿼리문에서 reflection으로 받아서 쿼리를 날리게 되는데 아무것도 없이 일반적인 update문만 날리면 에러가 나온다. 이런 경우 @Modifying 애너테이션을 붙이고 해당 쿼리를 사용하는 서비스단에서 @Transactional을 붙여주어야 정상적으로 동작할 수 있다.

중첩 클래스 어떤 상황에서 써야 할까 스프링에서 컨트롤러에서 Dto 자주 사용하는데 이 Dto는 메서드 마다 새로 만드는 경우가 많은데, 재사용할 상황이 많이 안생겨서 이걸 굳이 Dto 패키지를 만들어서 거기에 넣어두거나 특정 도메인 패키지에 넣어둘 필요 없이 그냥 중첩 클래스로 쓰는게 좋지 않나? 라는 생각에서 시작했다. 일단 중첩 클래스 정리 중첩 클래스는 선언위치에 따른 분류 선언위치 설명 멤버 클래스 인스턴스 멤버 클래스 class A{ class B{ ...} } A 클래스를 생성해야만 사용가능한 B 중첩 클래스 정적 멤버 클래스 class A{ static class B{...} } A 클래스로 바로 접근 가능한 B 중첩 클래스 로컬 클래스 class A{ void method(){ class..