끄적끄적 개발

이전 글에서는 가장 기본적인 프론트 컨트롤러의 구조에 대해서 알아보고 이를 구현해보았다. 사실 글을 쓰면서도 이렇게 까지 기본적인? 내용에 대해 글을 쓰고 코드로 구현을 해봐야 할까 싶었지만, 사실 스프링에서 구현된 프론트 컨트롤러 패턴은 매우매우 복잡해서 공부한 뒤 일주일만 지나도 이에 대해 확실하게 기억하기가 쉽지 않다. 그러나 아주 기본적이면서도 간단한 4개의 객체로만 구성된 구조를 파악하고 기억하는 것은 매우 쉬운데 이를 통해 오랫동안 스프링의 구조를 잘 기억할 수 있기를 바라며 글을 작성해 보았다. 또한 프레임워크를 한번도 공부해본 적이 없는 분들에게도 도움이 되지 않을까 한다. 각설하고 이번 글에서는 지난번에 구현했던 프론트 컨트롤러 패턴을 조금더 향상된 구조로 리팩토링하려고 한다. 지난 구조..

간단한 웹 프로그램을 한번이라도 개발해본 적이 있다면 웹 서버 또는 WAS에 대해 들어본 적이 있을 것이다. 이름도 비슷해서 혼동하기 쉬운데 이참에 둘의 개념을 확실히 이해해보자. 또한 스프링으로 개발된 프로그램이 서버에서 서비스될 때 어떤 프로세스로 요청이 처리되는지도 추가로 짚고 넘어가자. 웹 프로그램은 클라이언트의 HTTP 프로토콜에 기반한 요청에 대해 서버가 적절한 응답을 반환하는 식으로 동작한다. 즉 서버는 요청에 따른 리소스를 클라이언트에게 제공하는데, 이때 제공되는 리소스는 추가 처리 여부에 따라 정적 리소스, 동적 리소스로 구분될 수 있다. 먼저 정적 리소스는 별도의 서버에서의 처리 없이 단순히 조회되는 리소스로, 모든 사용자에게 동일하게 보여지며 예로는 HTML, CSS, JS, 이미지,..

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

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