코드로 작성해보는 토비의 스프링

객체지향의 세계도 모든 것이 변한다. 여기서 변한다는 것은 변수나 오브젝트의 필드의 값이 변한다는게 아니다. 오브젝트에 대한 설계와 이를 구현한 코드가 변한다.소프트웨어 개발에서 끝이란 없다.그래서 개발자가 객체를 설계할 때 미래의 변화를 대비하는 것이 중요하다.객체지

위 그림처럼 SimpleConnectionMaker라는 새로운 클래스를 만들고 DB 생성 기능을 넣는다. 그리고 UserDao는 new 키워드를 사용해서 SimpleConnectionMaker 클래스의 오브젝트를 만들고 이를 add(), get() 메서드에서 사용하면

1.4.1 오브젝트 팩토리 UserDaoTest는 기존에 UserDao가 직접 담당하던 기능, 즉 어떤 ConnectionMaker 구현 클래스를 사용할지를 결정하는 기능을 맡게되었다. UserDao 역할을 클라이언트인 UserDaoTest가 그 수고를 담당하게 된

스프링의 핵심을 담당하는 건, 바로 빈 팩토리 또는 애플리케이션 컨텍스트라고 불리는 것이다. 이 두가지는 우리가 만든 DaoFactory가 하는일을 좀 더 일반화한 것이라고 설명할 수 있다. 1.5.1 오브젝트 팩토리를 이용한 스프링 IoC 애플리케이션 컨텍스트와

DaoFactory를 직접 사용하는 것과 @Configuration 어노테이션을 추가해서 스프링 애플리케이션 컨텍스트를 통해 사용하는 것은 테스트 결과만 보면 동일한 것 같다. 하지만 그 둘은 중요한 차이점이 있다. 먼저 DaoFactory의 userDao() 메서드를

1.7.1 제어의 역전(IoC)과 의존관계 주입 IoC는 소프트웨어에서 일반적인 개념이다. DaoFactory처럼 객체를 생성하고 관계를 맺어주는 등의 작업을 담당하는 기능을 일반화한 것이 스프링의 IoC 컨테이너다. IoC라는 용어는 매우 폭넓게 사용되는 용어이다

스프링은 DaoFactory와 같은 자바 클래스를 이용하는 것 외에도, 다양한 방법을 통해 DI 의존관계 설정정보를 만들 수 있다. 가장 대표적인 것이 바로 XML이다. XML은 단순한 텍스트 파일이기 때문에 다루기 쉽다. 또, 쉽게 이해할 수 있으며 컴파일과 같

이전에 만들었던 테스트 코드는 main() 메서드를 이용해 UserDao 오브젝트의 add(), get() 메서드를 호출하고 그 결과를 화면에 출력해서 그 값을 눈으로 확인시켜준다.코드를 수정함에 따라 그것이 처음과 동일한 기능을 수행함을 보장해줄 수 있는 방법에는 테

첫 번째 문제점인 테스트 결과의 검증 부분을 코드로 만들어보자.모든 테스트는 성공과 실패의 두 가지 결과를 가질 수 있다. 또 실패는 테스트가 진행되는 동안에 에러가 발생해서 실패하는 경우와, 테스트 작업 중에 에러가 발생하진 않았지만 그 결과가 기대한 것과 다르게 나

JUnit은 사실상 자바의 표준 테스팅 프레임워크라고 불릴만큼 폭넓게 사용되고 있다. 스프링을 학습하고 제대로 활용하려면 최소한의 JUnit 테스트 작성 방법과 실행 방법은 알고 있어야 한다.스프링 프레임워크 자체도 JUnit 프레임워크를 이용해 테스트 해가며 개발됐다

이제 테스트 코드도 어느 정도 깔끔하게 정리했다. 하지만 아직 한 가지 찜찜한 부분이, 바로 애플리케이션 컨텍스트 생성 방식이다. @BeforeEach 메서드가 테스트 메서드 개수만큼 반복되기 때문에 애플리케이션 컨텍스드도 세 번 만들어진다. 지금은 설정도 간단하고 별

개발자가 자신이 만든 코드가 아닌 다른 사람이 만든 코드와 기능에 대한 테스트를 작성할 필요가 있을까? 일반적으로 애플리케이션 개발자는 자신이 만들고 있는 코드에 대한 테스트만 작성하면 된다. 하지만 때로는 자신이 만들지 않은 프레임워크나 다른 개발팀에서 만들어서 제공