Back-End/Spring

JUnit은 각각의 테스트가 독립적으로 존재할 수 있게 하기 위해 테스트 메서드마다 서로 다른 오브젝트를 만들어서 실행되게 한다. 하지만 이 경우가 스프링에서는 문제가 될 수 있는데 애플리케이션 컨텍스트를 테스트 오브젝트마다 반복적으로 만들기 때문에 빈이 많아지고 설정이 복잡해지는 경우에는 컨텍스트 생성에 시간이 많이 소요된다. 또한 여러 테스트가 함께 참조해야할 애플리케이션 컨텍스트를 오브젝트 레벨에 저장해두면 각각 다른 컨텍스트를 참조하게 되어 곤란하다. 이를 위해서 JUnit은 테스트 클래스 전체에서 딱 한 번만 실행되는 @BeforeClass 스태틱 메서드라는 기능을 제공한다. 물론 이 기능으로도 가능하지만 스프링에서 제공하는 더 좋은 방법이 있다. 스프링 테스트 컨텍스트 프레임워크 적용하기 @R..

JUnit 테스트 실행하기 IDE 자바 IDE에서는 대부분 내장된 JUnit 테스트 지원 도구가 존재한다. JUnit을 메인 메서드를 만들지 않고도 테스트를 진행할 수 있게 해주며, 테스트 정보를 표시해주는 다양한 뷰 기능도 제공한다. 빌드 툴 메이븐, 그래들 같은 빌드 툴에서 제공하는 JUnit 플러그인과 테스트가 존재한다. HTML이나 텍스트 파일 형식으로 보기 좋게 테스트 결과를 만들어주기 때문에 개인별로는 IDE를 통해서 테스트를 실행하지만 통합 빌드 후의 테스트는 빌드 툴을 통한 테스트 결과를 파일로 전달 받는다. 일관된 테스트 결과 테스트는 외부의 상태에 따라 결과가 달라지는 일이 발생하지 않고 코드의 변화가 있지 않는한 항상 같은 결과가 나와야 한다. 이를 위해서는 테스트한 결과는 실제로 반..

복잡한 엔터프라이즈 애플리케이션을 효과적으로 개발하기 위해서는 객체지향과 테스트 기술을 유연하게 다룰 줄 알아야한다. 코드가 정확히 동작하는지를 확인하며 코드나 설계의 결함을 파악하여 제거해가는 디버깅을 통해 최종적으로 모든 결함을 제거하여 개발한 코드를 확신할 수 있게 해주는 작업 객체지향 기술을 통해 확장과 변화를 고려한 프로그래밍을 할 수 있다면 테스트를 통해 이러한 프로그래밍 결과를 검증할 수 있게 해준다. 기존 테스트 방식의 문제점 기존의 웹 프로그램에서 테스트를 하기 위해서는 해당 기능과 관련된 모든 기능들을 약식으로라도 구현해두고 웹 화면을 띄워 입출력을 실행한 후 관련 기능들이 모두 제대로 동작하는지 일일히 확인을 해야했다. 일부 기능만 테스트하기 위한 작업치고는 해야할 일이 너무 많을 뿐..

XML 애플리케이션 컨텍스트 생성에 사용할 설정정보를 만드는 것은 반복적인 작업이 계속해서 이뤄진다. DI 구성이 바뀔 때마다 이런 반복적인 작업을 수행하는 것은 번거롭기 때문에 다양한 방법을 통해 이러한 설정정보를 만들 수 있는데 대표적인 방법이 XML이다. XML은 단순한 텍스트 파일이기 때문에 이해하기 쉽고 별도의 빌드 작업이 필요 없고 오브젝트의 관계 변경 사항에 대한 반영이 쉽고 빠르다. XML 설정 : @Configuration, 루트 엘리먼트로 사용 : @Bean, 빈을 정의(빈의 이름, 어떤 클래스를 사용해서 만들지, 의존 오브젝트) : 빈의 의존관계 정의 애플리케이션 컨텍스트 생성하기 : XML 이용 기존에는 설정정보를 사용하여 애플리케이션 컨텍스트를 생성하기 위해 AnnotationCo..

의존관계와 의존관계 주입 서로 의존하고 있는 관계라는 것은 한 쪽의 변화가 다른 한 쪽에 영향을 끼친거나 한 쪽이 다른 한 쪽의 멤버를 사용하는 경우 등이 의존관계에 있다고 볼 수 있다. 의존관계는 설계 모델에서의 의존 관계와 런타임 시에 만들어지는 의존관계가 있는데 스프링에서의 의존관계 주입은 이런 런타임 시의 의존관계가 있고, 이러한 런타임 시의 의존관계를 오브젝트 의존관계라고 한다. 즉, 실제 사용대상인 의존 오브젝트와 그것을 사용하는 주체(클라이언트) 오브젝트를 런타임 시에 연결해주는 작업을 해주는 것을 의존관계 주입(DI)이라고 한다. 의존관계 주입은 아래와 같은 세 가지 조건을 만족해야 한다. 클래스 모델 및 코드에는 런타임 시점의 의존관계가 드러나지 않게, 클래스와 클래스 간의 의존이 아닌 ..

오브젝트의 동일성과 동등성 동일성 오브젝트의 주소가 같다는 의미로 == 연산자를 통해서 비교한다. 즉, 서로 동일한 오브젝트라면 해당 오브젝트는 두 개가 아니라 하나만 존재하고 있다는 것 동등성 오브젝트의 정보가 같다는 내용으로 equals 메서드를 통해서 비교한다. 즉, 서로 동등한 오브젝트라면 오브젝트가 가지고 있는 내용은 같지만 주소는 다르므로 동등한 오브젝트는 하나가 아니라 두 개가 같은 내용으로 존재하고 있다는 것 equal 메서드를 따로 구현하지 않은 경우에는 Object 클래스에 있는 것을 사용하여 동일성을 비교함 팩토리와 애플리케이션 컨텍스트의 동일성 차이 스프링을 적용하지 않은 기존의 팩토리를 통해 오브젝트를 생성하는 경우에는 오브젝트가 생성될 때마다 항상 새로운 오브젝트가 생성 되어 주..

DaoFactory를 통해 간단하게 IoC가 무엇인지 알게 되었고 이제 이 팩토리를 스프링의 도움을 받아 IoC를 적용해본다. 빈 스프링이 제어권을 가지고 직접 만들고 관계를 부여하는 오브젝트 오브젝트 단위의 애플리케이션 컴포넌트 IoC가 적용된 오브젝트 빈 팩토리 빈의 생성, 관계설정 등의 제어를 담당하는 IoC 오브젝트 이를 더 확장한 애플리케이션 컨텍스트를 주로 사용 애플리케이션 컨텍스트 애플리케이션 설정정보를 바탕으로 빈의 생성과 관계설정을 총괄하는 IoC 엔진 같은 역할 애플리케이션 컨텍스트 적용하기 : 설정정보 생성하기 팩토리는 애플리케이션의 설계도 같은 것이라고 했는데 이말은 팩토리를 애플리케이션 컨텍스트의 설정정보로 사용할 수 있다는 것이다. @Configuration 어노테이션을 사용하여..

오브젝트 팩토리 팩토리 객체의 생성 방법을 결정하고 만들어진 오브젝트를 돌려주는 일을 하는 오브젝트 public class UserDaoFactory { public UserDao userDao() { UserDao dao = new UserDao(connectionMaker()); return dao; } public ConnectionMaker connectionMaker() { ConnectionMaker connectionMaker = new DConnectionMaker(); return connectionMaker; } } 팩토리는 ConnectionMaker 메서드를 통해 어떤 커넥션 메이커를 사용할지 정하고 UserDao 메서드를 사용하여 최종적으로 UserDao 오브젝트를 리턴한다. pu..