본문 바로가기

토비의 스프링 정리

토비의 스프링 - 2.6 2장 정리 2.6.1 정리 테스트는 자동화 및 빠른 실행을 해야함 main() 테스트 대신 JUnit 프레임워크를 이용한 테스트가 편리함 테스트 결과는 일관성 있어야 함. 환경이나 테스트 실행 순서에 따라 결과가 달라지면 안됨 테스트는 포괄적으로 작성해야 함. 충분한 검증이 이루어지지 않은 테스트는 없는것 보다 나쁨 코드 작성과 테스트 수행 간격이 짧을수록 효과적 테스트를 하기 쉬운 코드가 좋은 코드임 TDD 개발 방법은 매우 유용함 테스트 코드도 적절한 리팩토링 필요 @Before과 @After은 공통 중비 작업과 정리 작업을 처리할수 있음 스프링 테스트 컨텍스트 프레임워크를 이용하면 테스트 성능을 향상할 수 있음 동일 설정파일을 이용하면 하나의 애플리케이션 컨텍스트를 공유하도록 함 @Autowired를 사용하면.. 더보기
토비의 스프링 - 2.5 학습 테스트로 배우는 스프링 2.5.1 학습 테스트(Learning Test) 자신이 만들지 않은 프레임워크나 라이브러리 등의 테스트를 작성하는 것 자신이 사용할 API나 프레임워크의 기능을 테스트로 보면서 사용법을 익힘 프레임워크등 기능 검증 목적이 아님. 개발자의 이해도와 사용 방법을 검증하는 것임 학습 테스트를 통해 잘못된 지식이 바로잡기도 함 테스트 대상보다 테스트 코드 자체에 관심을 가져야 함 2.5.2 학습 테스트의 장점 다양한 조건에 따른 기능을 손쉽게 확인해 볼 수 있음 예제를 만들면서 학습을 하는것은 수동 테스트와 성격이 비슷함 반면에 학습 테스트는 자동화된 테스트 코드로 만들어지기 때문에 다양한 조건에 따라 기능이 어떻게 동작하는지 빠르게 확인 할 수 있음 학습 테스트 코드를 개발 중에 참고할 수 있음 수동 테스트.. 더보기
토비의 스프링 - 2.4 스프링 테스트 적용 2.4.1 기존 테스트의 문제점 @Test 애노테이션이 붙은 메소드를 테스트 할 때 마다 매번 새로운 오브젝트가 만들어지기 때문에, 매번 새로운 애플리케이션 컨텍스트가 생성됨 애플리케이션 컨텍스트에 있는 빈들이 초기화 시점에 많은 리소스를 할당하거나 스레드를 띄우는 경우가 발생해 테스트 안정성 및 속도가 떨어짐 빈은 싱글톤으로 만들어지기 때문에 상태를 가지지 않음(add(), get()을 한다고 해도 빈의 상태가 변경되지는 않음) 때문에 애플리케이션 컨텍스트를 매번 만들지 않고 공유를 해도 상관 없음 @BeforeClass 애노테이션은 테스트 클래스 전체에 딱 한번만 생성되는 스태틱 메소드를 만듦 스태틱으로 애플리케이션 컨텍스트를 저장해서 사용해도 되지만, 스프링이 직접 제공하는 애플리케이션 컨텍스트 테.. 더보기
토비의 스프링 - 2.3 개발자를 위한 테스팅 프레임워크 JUnit 2.3.1 JUnit 테스트 실행 방법 JUnitCore를 이용한 방법은 테스트의 수가 많아지면 관리하기 힘듦 IDE에서 지원하는 방식을 사용하면 편함 이클립스 IDE는 여러 정보를 보여줌 총 수행시간 실행한 테스트의 수 테스트 에러의 수 테스트 실패의 수 어떤 테스트 클래스를 실행했는지 @Test가 붙은 테스트 메소드의 이름 각 테스트 메소드와 메소드 수행 시간 빌드 툴에서 제공하는 JUnit 플러그인이나 태스트를 이용해 테스트 할 수 있음 테스트 결과를 HTML이나 텍스트 파일 형태로 추출 가능 2.3.2 deleteAll()의 getCount() 추가 현재 테스트는 수행되기 전에 수작업으로 DB의 데이터를 일일이 초기화 해야함 테스트가 외부 상태에 따라 결정되기도 함 add()의 데이터와 동일한 데.. 더보기
토비의 스프링 - 2.2 UserDaoTest 개선 2.2.1 테스트 검증의 자동화 add()와 get()을 통해 다시 DB에서 가져온 User 오브젝트의 정보가 정확히 일치하는가를 테스트 add()를 통한 등록 자체는 별다르게 검증할 것이 없음. add()이후 별다른 에러가 발생하지 않으면 성공으로 간주 add()를 통해 등록이 되지 않았다면, get()을 통해 가져오지 못할 것 이므로 get()을 통해 add()의 작업도 함께 확인 테스트 실패 종류 테스트 에러 테스트가 진행되는 동안에 에러가 발생해서 실패 테스트 실패 에러가 발생하진 않았지만, 결과가 기대한 것과 다르게 나오는 경우 main()은 제어권을 직접 가지므로, 프레임워크의 기본 동작원리인 IoC가 아니다. 따라서 프레임워크(스프링)에 main()을 사용하는 테스트는 적합하지 않음 Java.. 더보기
토비의 스프링 - 2.1 UserTest 다시 보기 2.1.1 테스트의 유용성 예상하고 의도했던 대로 코드가 정확히 수행되는지 검증 코드 수행 검증을 할 수 있는 테스트 코드 덕분에 코드 개선(리팩토링) 가능 기능을 추가할 때 유용하게 사용 가능하여 점진적 개발 가능 모든 기능을 구현하지 않아도 코드가 정상 동작하는지 확인 가능 💡 로그인 기능 웹사이트를 구현할 때 테스트가 없다면 파싱, DB 연결, SQL 실행 등 어디서 문제가 발생했는지 확인하기 어려움 2.1.2 작은 단위의 테스트 명확한 테스트 대상에만 집중해서 테스트하는 것이 바람직함 한번에 많은 테스트 대상을 테스트하면 어디서 오류가 발생하는지 찾기 어려움 테스트는 가능하면 작은 단위로 쪼개서 집중할 수 있어야 함 작은 단위의 코드에 대해 테스트 수행한 것을 단위 테스트(Unit Test)라 함.. 더보기
토비의 스프링 - 1.9 1장 정리 1.9.1 정리 책임이 다른 코드를 분리(DB연결, DB실행)해서 두 개의 클래스로 만들었다.(관심사의 분리, 리팩토링) 바뀔 수 있는 쪽의 클래스는 인터페이스를 구현하게 하고, 다른 클래스에서 인터페이스를 통해 접근하도록 함. 정의하는 쪽의 구현 방법이 달라져 클래스가 변경되더라도, 그 기능을 사용하는 코드는 같이 수정할 필요가 없어짐(전략 패턴) 외부 오브젝트의 기능은 자유롭게 확장, 변경할 수 있도록 함(개방 폐쇄 원칙) 낮은 결합도와 높은 응집도 코드가 되어 코드가 깔끔해짐 제어권을 별도의 오브젝트 팩토리를 만들어 넘김.(제어의 역전/IoC) 전통적 싱글톤 패턴의 단점과 스프링의 싱글톤 레지스트리를 이용하여 싱글톤의 단점을 극볼할 수 있도록 함 설계 시점과 코드에는 클래스와 인터페이스 사이의 느슨.. 더보기
토비의 스프링 - 1.8 XML을 이용한 설정 1.8.1 XML 사용 이유 오브젝트 사이의 의존정보를 일일이 자바 코드로 만들기 번거로움 자바코드는 틀에 박힌 구조 XML은 자바 코드와 달리 별도의 빌드 작업이 없고, 빠르게 변경사항 반영 가능 스키마나 DTD(Document Type Definition)을 사용해 정해진 포맷으로 작성 되었는지 확인 가능 1.8.2 XML 설정 DI 정보가 담긴 XML 파일은 를 루트 엘리먼트로 사용 태그로 빈 설정 XML 설정은 자바의 @Configraion, @Bean 설정과 동일 💡 @Configraion은 , @Bean은 과 같다고 생각하면 됨 @Bean 메소드를 통해서 얻을 수 있는 세 가지 정보 빈의 이름(id) @Bean 메소드 이름이 빈의 이름. 이 이름은 getBean() 에서 사용됨 빈의 클래스(c.. 더보기

티스토리툴바