Spring/토비의 스프링 3.1 썸네일형 리스트형 2.5 학습 테스트로 배우는 스프링 2.5 학습 테스트로 배우는 스프링 학습 테스트 자신이 만들지 않은 프레임워크나 다른 개발팀에서 만들어서 제공한 라이브러리 등에 대해서 작성한 테스트 학습 테스트의 목적 사용할 API나 프레임워크의 기능을 테스트로 보면서 사용 방법을 익히기 위함 자신이 테스트를 만들려고 하는 기술이나 기능에 대해 얼마나 제대로 알고 있는 지를 검증 빠르고 정확하게 사용법을 익히기 위함 테스트 대상보다 테스트 코드 자체에 관심을 가져야 함 2.5.1 학습 테스트의 장점 다양한 조건에 따른 기능을 손쉽게 확인 가능 자동화된 테스트 코드로 만들어지기 때문에 다양한 조건에 따라 기능이 어떻게 동작하는지 빠르게 확인이 가능 학습 테스트 코드를 개발 중 참고 가능 예제를 만드는 방법의 경우 최종 수정 예제만 남게 된다. 학습 테스.. 2.4 스프링 테스트 적용 애플리케이션 컨텍스트 생성 방식 @Before 메소드가 테스드 메소드 개수만큼 반복 반복될 때마다 애플리케이션 컨텍스트가 만들어짐 애플리케이션 컨텍스트 생성 시 모든 싱글톤 빈 오브젝트를 초기화하므로 제법 많은 시간을 필요로 함 테스트는 가능한 독립적으로 매번 새로운 오브젝트를 사용하는 것이 원칙 애플리케이션 컨텍스트처럼 시간과 자원이 많이 소모되는 경우 테스트 전체가 공유하는 오브젝트를 만들기도 함 다만, 이 때도 테스트는 일관성이 있어야하며, 테스트 순서에 영향을 받지 말아야한다. 애플리케이션 컨텍스트의 경우 초기화되고 나면 내부 상태가 변경되는 일이 거의 없으므로 무관함 문제는 JUnit이 매번 테스트 클래스의 오브젝트를 새로 생성함. 여러 테스트가 함께 참조할 애플리케이션 컨텍스트를 오브젝트 레벨.. 2.3 개발자를 위한 테스팅 프레임워크 JUnit 목차 2.3.1 JUnitTest 실행 방법 IDE 빌드툴 2.3.2 테스트 결과의 일관성 deleteAll()의 getCount() 추가 deleteAll()과 getCount()의 테스트 동일한 결과를 보장하는 테스트 2.3.3 포괄적인 테스트 getCount() 테스트 addAndGet() 테스트 보완 get() 예외조건에 대한 테스트 테스트를 성공시키기 위한 코드의 수정 포괄적인 테스트 2.3.4 테스트가 이끄는 개발 기능설계를 위한 테스트 테스트 주도 개발 2.3.5 테스트 코드 개선 @Before 픽스처 2.3.1 JUnit 테스트 실행 방법 JUnitCore를 이용해 테스트를 실행할 수도 있지만, 테스트의 수가 많아지고 복잡해지면 관리하기가 힘들어짐 IDE 이클립스, STS는 JUnit 테스.. 2.2 UserDaoTest 개선 목차 2.2.1 테스트 검증의 자동화 2.2.2 테스트의 효율적인 수행과 결과 관리 JUnit 테스트로 전환 테스트 메소드 전환 검증 코드 전환 JUnit 테스트 실행 2.2.1 테스트 검증의 자동화 add()에 전달한 User 오브젝트와 get()을 통해 가져와 User 오브젝트의 정보가 서로 일치하는가 테스트 에러 : 테스트 진행 중 에러(Exception 등)가 발생 테스트 실패 : 에러는 발생하지 않았지만, 결과값이 다를 때 '조회 성공'은 에러가 발생하지 않았음을 의미할 뿐 테스트의 실패 여부는 알 수 없음 수정한 UserDaoTest() public static void main(String[] args) throws ClassNotFoundException, SQLException{ // ... 2.1 UserDaoTest 다시보기 목차 2.1.1 테스트의 유용성 2.1.2 UserDaoTest의 특징 웹을 통한 DAO테스트 방법의 문제점 작은 단위의 테스트 자동수행 테스트 코드 지속적인 개선과 점진적인 개발을 위한 테스트 2.1.3 UserDaoTest의 문제점 2.1.1 테스트의 유용성 UserDaoTest() + main() 메소드를 이용한 add(), get() 메소드의 동작 확인 + 테스트가 있었으므로 다양한 방법으로 UserDao의 코드의 설계와 코드를 개선 + 테스트 : 내가 예상하고 의도했던 대로 코드가 정확히 동작하는지를 확인 -> 만든 코드에 대한 확신 2.1.2 UserDaoTest의 특징 UserDaoTest public class UserDaoTest { public static void main(String.. 2장. 테스트 개요 스프링이 개발자에게 제공하는 가장 중요한 가치 객체지향 IoC와 DI : 오브젝트의 설계와 생성, 관계, 사용에 관한 기술 IoC/DI를 이용하여 객체지향 프로그래밍 언어의 근본과 가치를 개발자가 손쉽게 적용하고 사용할 수 있도록 도와줌 테스트 애플리케이션은 계속 변하고 복잡해져간다. 만들어진 코드을 확신할 수 있게 해 줌 변화에 유연하게 대처할 수 있는 자신감을 줌 목차 2.1 UserDaoTest 다시 보기 2.1.1 테스트의 유용성 2.1.2 UserDaoTest의 특징 웹을 통한 DAO테스트 방법의 문제점 작은 단위의 테스트 자동수행 테스트 코드 지속적인 개선과 점진적인 개발을 위한 테스트 2.1.3 UserDaoTest의 문제점 2.2 UserDaoTest 개선 2.2.1 테스트 검증의 자.. 1장. 오브젝트와 의존관계 개요 스프링은 자바를 기반으로 한 기술이다. 가장 중요하게 생각하는 가치 : 객체지향 가장 관심을 많이 두는 대상 : 오브젝트 목차 1.1 초난감 DAO 1.1.1 User 1.1.2 UserDao 1.1.3 main()을 이용한 DAO 테스트 코드 1.2 DAO의 분리 1.2.1 관심사의 분리 1.2.2 커넥션 만들기의 추출 UserDao의 관심사항 중복 코드의 메소드 추출 변경 사항에 대한 검증: 리팩토링과 테스트 1.2.3 DB 커넥션 만들기의 독립 상속을 통한 확장 1.3 DAO의 확장 1.3.1 클래스의 분리 1.3.2 인터페이스의 도입 1.3.3 관계설정 책임의 분리 1.3.4 원칙과 패턴 개방 폐쇄 원칙 높은 응집도와 낮은 결합도 전략 패턴 1.4 제어의 역전(IoC) 1.4.1 오브젝트 팩.. 1.9 정리 책임이 다른 코드를 분리하여 두 개의 클래스를 만듦(관심사의 분리, 리팩토링) 바뀔 수 있는 쪽의 클래스는 인터페이스를 구현하고, 다른 클래스는 인터페이스를 통해 접근(전략 패턴) 자신의 책임 자체가 변경되는 경우 외에는 불필요한 변화가 발생하지 않도록 막아주고, 자신이 사용하는 외부 오브젝트의 기능은 자유롭게 확장하거나 변경할 수 있도록 만듦(개방 폐쇄 원칙) 한쪽의 기능 변화가 다른 쪽은 기능 변경을 요구하지 않아도 되며(낮은 결합도), 자신의 책임과 관심사에만 순수하게 집중(높은 응집도)할 수 있게 됨 오브젝트가 생성되고 여타 오브젝트와 관계를 맺는 작업의 제어권을 별도의 오브젝트 팩토리 또는 IoC 컨테이너로 넘겨서 오브젝트가 자신이 사용할 대상의 생성이나 선택에 관한 책임으로부터 자유롭게 만들어.. 이전 1 2 3 4 5 다음
