끄적끄적 개발

지난 글에서는 Mockito로 mock 객체를 만들고 JUnit과 함께 간단한 테스트를 작성하는 방법과 여러 Mockito 어노테이션에 대해 알아보았다. 이번 글에서는 Mockito를 사용하여 Spring Boot에서 Service 계층을 어떻게 테스트하면 좋을지 여러 테스트 케이스들을 살펴볼 것이다. Mockito에 대한 기본 개념이 궁금하신 분들은 이전 글을 먼저 참고하시길. 스프링 부트에서는 Mockito, JUnit 라이브러리가 자동으로 포함되기 때문에 별도의 설정없이도 테스트 코드를 작성할 수 있다. 그럼 테스트를 작성하기 위해 간단하면서도 의미있는 어플리케이션을 먼저 개발해보자. 이 어플리케이션은 Member, Team 엔티티로만 구성되며, 각 Member는 하나의 Team에 소속된다. (즉 ..

클래스 간 의존관계가 없는 자바 어플리케이션에서는 JUnit만으로도 테스트가 가능하다. 그러나 스프링의 핵심 개념인 DI(Dependency Injection), 즉 의존관계 주입으로 인해 각 클래스 간 의존관계가 생겨 테스트가 힘들어지게 된다. 대표적인 예를 들어보자. 스프링으로 웹 개발을 할 때 일반적으로 Controller - Service - Repository 계층을 구성하며 Controller는 Service를, 다시 Service는 Repository를 의존하게 된다. 이때 Service 계층을 테스트하려고 테스트 코드를 작성하고 실행 버튼을 눌렀더니 테스트에 실패했다. 비즈니스 로직은 아무리 봐도 잘못된 것이 없는데... 아뿔싸 Service가 의존하고 있던 Repository 계층에 잘못..

이번 글에서 정리할 전략 패턴 또한 템플릿 메소드 패턴과 같이 알고리즘의 전체적인 구조는 고정되고 일부 로직의 구현만이 변경될 경우 사용할 수 있는 패턴이다. 이 두 패턴의 가장 큰 차이점은 패턴을 구현하는 방법으로, 템플릿 메소드 패턴은 상속을, 전략 패턴은 위임을 이용한다. 그럼 왜 굳이 비슷한 기능을 하는 패턴을 구현 방법에 따라 2개로 나눠놨을까? 의문이 들 것이다. 템플릿 메소드 패턴에서 알고리즘의 구체적인 구현은 상속을 통해 자식 클래스에서 이뤄진다. 이때 템플릿 즉 알고리즘의 전체적인 틀을 정의하는 부모 클래스의 메소드들까지도 자식 클래스에게 상속된다. 즉 자식 클래스는 자신이 실제로 사용하지 않는 부모 클래스의 기능까지도 상속받게 되고 이로 인해 부모 클래스의 변경이 불필요하게 자식 클래스..

서비스를 개발하다 보면 같은 로직을 다른 방식으로 구현해야 하는 경우가 많다. 예를 들어 할인 정책을 등급에 따라 다르게 적용하거나 지도 서비스에서 최적의 경로를 찾을 때 비용이 적게 드는 경로 또는 소요 시간이 짧은 경로를 찾는 등, 할인 적용 또는 경로 찾기라는 알고리즘의 구현을 다르게 해야 하는 경우이다. 이와 같이 알고리즘의 큰 틀, 구조는 같으면서 일부, 세부적인 동작만이 다른 경우, 변화에 유연한 구조와 낮은 코드 중복도를 위해 적용할 수 있는 디자인 패턴이 있다. 바로 템플릿 메소드 패턴과 전략 패턴인데, 이번 글에서는 템플릿 메소드 패턴에 대해 자세히 알아보고자 한다. 템플릿 메소드 패턴과 전략 패턴은 디자인 패턴 분류 중 행위(Behavioral) 패턴에 속한다. 행위 패턴은 '객체들 간..