테스트
스프링의 핵심인 Ioc 와 DI는 오브젝트의 설계와 생성, 관계 사용에 관한 기술.
출처: https://jobc.tistory.com/30 // 개념 되짚어 보기~
테스트의 유용성
웹을 통한 DAO 테스트 방법의 문제점
프론트 백엔드 다개발하고나서 확인해야되서 번거롭다.
어디서 발생하는지도 문제임.
작은 단위의 테스트
단위 테스트.
작은단위로 단위 테스트를 거쳐서 긴 테스트를 하면 오류가 훨씬 줄어듬.
개발자 테스트 또는 프로그래머 테스트 라고 함
자동수행 테스트 코드
자주 반복할 수 있는 장점
지속적인 개선과 점진적인 개발을 위한 테스트
미리 테스트 코드를 만들어두면 앞으로 기능을 추가하거나 변경할때 안전함
UserDaoTest의 문제점
수동 확인 작업의 번거로움
add 한뒤 Get 과정에 검증이 없음
실행 작업의 번거로움
메인 메소드를 실행해야되기때문에 좀 더 테스트를 나눠서해야됨
테스트 검증의 자동화
테스트의 효율적인 수행과 결과 관리
Junit을 통한 단위 테스트
테스트 메소드 전환
main() 메소드 테스트는 제어 권한을 직접 갖는다는 의미로 프레임워크에 적합하지 않다
- 메소드는 public으로
- 어노테이션 @Test 붙여주기
검증 코드 전환
assertThat 검증 함수
Junit 테스트 실행
개발자를 위한 테스팅 프레임워크 Junit
Junit 테스트 실행 방법
IDE에 내장된 Junit 테스트 지원 도구를 사용하는 것이다. (편리함)
테스트 결과의 일관성
포괄적인 테스트
getCount() 0,1에 대한 검증은 끝났으나 그이상의 수가나올경우? 좀더 꼼꼼히 해야됨
getCount() 테스트
테스트 메소드는 한번에 한 가지 검증 목적에만 충실한 것이 좋음.
addAndGet() 보완
get() 예외조건에 대한 테스트
Id가 없을 경우?
테스트를 성공시키기 위한 코드의 수정
포괄적인 테스트
항상 네거티브 테스트를 먼저 만들라.
위에 사항 처럼..
테스트가 이끄는 개발
TDD 의 시작 ..? 내용
기능설계를 위한 테스트
테스트 주도 개발
실패한 테스트를 성공시키기 위한 목적이 아닌 코드는 만들지 않는다.
스프링은 테스트하기 편리한 구조의 애플리케이션을 만들게 도와주고 빠르고 쉽게 작성할수있는 기능을 제공함
테스트 코드 개선
테스트코드 리팩토링
중복되는 코드를 제거하자
Junit 테스트 실행순서
각 테스트가 서로 영향을 주지않고 독립적으로 실행됨을 확실하게 보장해주기 위해
매번 새로운 오브젝트를 만들게 한다.
픽스처
테스트에 필요한 정보나 오브젝트를 픽스쳐라 함
UserTest에서 Dao가 대표적인 픽스처
add 메소드에 전달하는 User도 픽스처
스프링 테스트 적용
애플리케이션 생성 방식이 아쉬움
@Before 메소드가 테스트 메소드 개수만큼 반복되기 때문에 애플리케이션 컨텍스트도 세번 만들어짐
애플리케이션 컨텍스트는 많은 생성시간과 자원을 소모한다.
그래서 한번만 만들고 공유해서 사용해도 됨
테스트를 위한 애플리케이션 컨테긋트 관리
테스트 메소드의 컨텍스트 공유
Context 세번 모두 동일
같은 공간을 사용하기 때문에 테스트 속도가 빨라진다.
테스트 클래스의 컨텍스트 공유
@Atutowird
스프링 DI에 사용되는 특별한 애노테이션 .
오토와이어드가 붙어있으면 테스트 컨텍스트 프레임워크는 변수 타입과 일치하는 컨텍스트 내의 빈을 찾는다.
자동와이어링이라고 하며 빈을 자동으로 가져온다.
컨텍스트가 갖고있는 빈을 바로 DI 할 수 있다.
어노테이션을 지정하기만 한다면 어떤 빈이든 다 가져올 수 있다.
@Autowird는 변수에 할당 가능한 타입을 가진 빈을 자동으로 찾는다.
하지만 두개 이상의 같은 타입 빈은 어떤 빈을 가져올지 결정 할수 없음
DI와 테스트
어떤경우라도 인터페이스를 두고 DI를 적용해야된다
-
소프트웨어 개발에 절대 바뀌지 않는 경우는 없다.
-
클래스의 구현방식이 바뀌지 않는다 하더라도 인터페이스를 의존성 주입해두면 다른 차원의 서비스기능을 도입하기때문
ex) 앞에 잇는 카운트 메소드 -
테스트 때문 테스트를 손쉽게만들기위해서라도 ...
테스트 코드에 의한 DI
테스트를 위한 별도의 DI 설정
테스트 코드에서 수동으로 DI 방법은 단점이 많음
코드가 많아져서 번거롭거나.. 애플리케이션 컨텍스트도 매번 새로만들어야됨..
여기서는 프로퍼티를 서버운영환경마다 다르게? 라는 방법을 알려주는거 같은데 XML 설정을ㅇ ㅣ용하네..
컨테이너 없는 DI 테스트
DI를 이용한 테스트 방법 선택
항상 스프링 컨테이너가 없이 테스트 할수 있는 방법을 우선적으로 고려하자
학습 테스트로 배우는 스프링
학습 테스트: 다른 사람이 만든 코드나 프레임워크 라이브러리등에서 테스트 를 작성해야되는 경우
이런 경우 그 프레임워크나 라이브러리 다른사람의 개발코드의 기능을 알아보기위해서다
학습테스트의 장점
-
다양한 조건에 따른 기능을 손쉽게 확인해볼 수 있다.
예제를 만들면서 테스트 하는건 = 수동테스트
학습테스트는 자동화된 테스트 코드로 만들어지기 때문에 다양한 조건에따라 어떻게 동작하는지 가능
-
학습테스트 코드 개발중 참고 가능
다른 사람이 만든 코드를 참고하면서 테스트 코드를 작성하기 때문?
-
프레임워크나 제품을 업그레이드 할때 호환검 검증을 도와준다.
학습테스트를 이용하면 이전 버전에 기능에 문제가 없는지 미리 확인가능
-
테스트 작성에 대한 좋은 훈련이 된다.
-
새로운 기술을 공부하는 과정이 즐거워진다.
학습 테스트 예제
Junit 테스트 오브젝트 테스트
Junit 테스트 메소드를 수행할때 마다 매번 새로운 오브젝트가 만들어 질까?
첫번째는 검증을 통과햇지만 1 - 3 은 같은 주소이지 않을까?
결론 : 매번 새로운 오브젝트가 만들어진다.
스프링 테스트 컨텍스트 테스트
테스트에는 여러가지 방법있지만 assertThat이 사용하는ㄱ ㅔ좋을거같음
버그 테스트
오류가 있을때 그 오류를 가장 잘 드러내줄 수 있는 테스트
일단 실패하도록 만들어야됨 .. 그리고 수정
- 테스트의 완성도 높여준다.
- 버그의 내용을 명확하게 분석해줌
- 기술적인 문제를 해결하는데 도움이 된다.
정리
테스트는 자동화돼야 하고 빠르게 실행할 수 있어야 함.
main() 테스트 대신 Junit 프레임워크를 이용한 테스트 작성이 편리하다.
테스트 결과는 일관성이 있어야 한다. 코드의 변경 없이 환경이나 테스트 실행 순서에 따라서 결과가 달라지면 안 된다.
테스트는 포괄적으로 작성해야 한다. 충분한 검증을 하지 않는 테스트는 없는 것 보다 나쁠 수 있다.
코드 작성과 테스트 수행의 간격이 짧을수록 효과적이다.
테스트하기 쉬운 코드가 좋은 코드다.
테스트를 먼저 만들고 테스트를 성공시키는 코드를 만들어 가는 테스트 주도 개발방법도 유용하다.
테스트 코드도 애플리케이션 코드와 마찬가지로 적절한 리팩토링이 필요하다.
@Before , @After를 사용해서 테스트 메소드들의 공통 준비 작업과 정리 작업을 처리 할 수 있다.
스프링 테스트 컨텍스트 프레임워크를 이용하면 테스트 성능을 향상시킬수 있다.
동일한 설정파일을 사용하는 테스트는 하나의 애플리케이션 컨텍스트를 공유한다.
@Autowird를 사용하면 컨텍스트의 빈을 테스트 오브젝트에 DI 할수 있다.
기술의 사용 방법을 익히고 이해를 돕기위해 학습테스트를 작성하자
오류가 발견될 경우 그에 대한 버그 테스트를 만들어두면 유용하다.
스프링을 사용하는 개발자라면 자신이 만든 코드를 테스틀 ㅗ검증하는 방법을 알고
있어야 하며, 테스트를 개발에 적극적으로 활용할 수 있어야 한다.
