끄적끄적 개발

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

웹 어플케이션 프레임워크의 구조에 대해서 조금이라도 공부해본 적이 있다면 Front Controller 패턴에 대해 들어본 적이 있을 것이다. 프론트 컨트롤러는 간단히 "웹 어플리케이션에서의 모든 요청을 앞단에서 처리하는 핸들러"라고 정의할 수 있는데, 이러한 구조는 코드 중복을 줄이고 유연성과 재사용성을 높여주기 때문에 많은 웹 프레임워크에서 프론트 컨트롤러 패턴을 채택하고 있다. 사실 이 정도의 정의만 이해하고 넘어가도 프레임워크를 단순히 사용하는데에는 지장이 없겠지만 프레임워크의 전체적인 구조가 어떻게 생겼는지 이해하는 것도 분명 필요하다. 따라서 기본적인 프론트 컨트롤러 패턴은 어떻게 구현되는지, 스프링에서는 이 패턴을 어떤 식으로 변형하여 MVC 구조를 구현해냈는지, 더 나아가 스프링에서 프론트..

대부분의 테스트는 특정 메소드에 특정 인자를 전달하였을 때 기대한 값이 맞는지 확인하는 방식으로 이루어진다. 이때 전달하는 인자로 일반적인 값뿐만 아니라 edge case 혹은 corner case 등까지 포함해야 제대로 된 테스트라 할 수 있다. 아래와 같이 A 클래스에서 인자로 전달된 값을 바로 반환하는 메소드를 테스트한다고 가정해보자. 메소드가 제대로 동작하는지 확인하기 위해서는 하나의 값 뿐만 아니라 다양한 케이스에 해당하는 값들을 인자로 넘겨 테스트를 수행해야 한다. 그런데 아래와 같이 get 테스트 대상 메소드에 전달하는 인자 별로 테스트 메소드를 분리하게 되면, 중복 코드가 많아지고 테스트 클래스의 크기도 커져 무엇을 테스트 하고 있는지 한눈에 알아보기 어려워진다. 따라서 JUnit에서는 테..

지난 글에서는 JUnit이 제공하는 Assertions에 대해 알아보았다. 이번에 알아볼 AssertJ의 Assertions는 JUnit의 Assertions 보다 더 유연하고 가독성 있는 테스트 코드를 작성할 수 있게 해주며, 특히 자바 8의 함수형 프로그래밍의 특징들을 잘 활용할 수 있게 해준다. 그럼 이 AssertJ가 뭔지 간단히 살펴보고 AssetJ의 Assertions 메소드들을 자주 사용하는 것들 위주로 정리해보자. JUnit 자바 기반 테스트 자동화 프레임워크 AssertJ 자바 기반 테스트에서 Assertions를 작성하기 위한 오픈소스 라이브러리 즉 JUnit에 비해 AssertJ가 Assertion에 더 특화되어 있다고 보면 된다. 자바에서 AssertJ를 사용하기 위해서는 build..