끄적끄적 개발

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

단위 테스트에서는 특정 메소드의 반환값이 예상값과 같은지, 메소드 호출 시 전달되는 인자에 따라 특정 예외가 발생하는지 등을 검증해야 한다. 이를 위해 실제 if문 또는 try-catch문 등을 사용하여 직접 검증할 수도 있지만 자바에서는 보다 편리하게 이를 수행할 수 있는 방법이 존재한다. 이번 글에서는 조금 쉬어가는 타임으로 JUnit이 제공하는 검증을 위한 유틸리티 메소드인 Assertions에 대해 알아보고자 한다. 자바에서 단위 테스트를 한번이라도 해본적이 있다면 Assertions 클래스를 제공하는 2개의 패키지가 있다는 것을 알 것이다. 바로 JUnit과 AssertJ이다. 먼저 JUnit의 Assertions 메소드를 자주 사용하는 것들 위주로 살펴보자. assertEquals & asse..

저번 글에 이어서 Effective Java 스타일의 Builder 패턴과 @Builder 어노테이션에 대해 알아보자. 먼저 이번 글에서 계속해서 사용할 예제 클래스는 다음과 같다. @AllArgsConstructor(access = AccessLevel.PROTECTED) public class Home { private String basement; private String structure; //required private int door; //required private int window; //required private String roof; //required private String interior; } Effective Java의 Builder Pattern 앞의 글과는 다르게 ..

그동안 스프링으로 개발을 하면서 아무 생각없이 @Builder 어노테이션을 사용하여 객체를 생성해왔다. 그러던 어느날 필드가 7개나 되는 객체를 builder() 메소드를 호출하여 생성하던 중 이거 잘못하다 필드 하나 빠뜨리겠는데? 라는 생각이 들었다. 또한 어떤 필드에 대한 메소드를 호출해야 하는지 기억이 나지 않아 해당 클래스 파일을 왔다갔다하며 객체를 생성할 수 밖에 없었다. 물론 builder() 메소드 호출을 통한 객체 생성 시에도 IDE의 도움을 받을 순 있지만 필드의 갯수가 매우 많은 경우에는 헷갈릴 가능성이 많다. 무엇보다 만약 필수적인 필드를 빠뜨렸을 때 일반 생성자의 경우에는 컴파일 오류가 발생하여 이를 금방 알아차릴 수 있다. 그러나 @Builder의 경우에는 실행 오류만이 발생한다...