요즘 진행하고 있는 토이 프로젝트에서 어느정도 API 구현이 끝난 후 "현재 이 서버가 얼마나 많은 부하를 감당할 수 있을까?" 라는 생각이 들었습니다. 그래서 성능을 테스트하고자 네이버 오픈소스 프로젝트인 nGrinder를 사용하여 서버에 부하를 걸고 테스트를 해보았습니다. (http://naver.github.io/ngrinder/) 테스트로 선택한 API는 현재 서버에서 가장 비용이 비싸다고 생각되는 API(한 트랜잭션안에 제일 많은 조인 쿼리와 실제 나가는 쿼리 수가 많음)를 선택하여 성능을 테스트 하였고 이후 성능 개선을 위해 캐시를 적용했습니다. 이러한 테스트는 여러개의 서버를 두고 해야 정확한 테스트가 가능하지만 제가 가진 서버는 오직 제 컴퓨터 한 대와 이미 사용중인 EC2 한 대 이므로 ..

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

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..