테스트
내가 예상하고 의도했던 대로 코드가 정확히 동작하는지 확인하는 것
동작을 통해 코드를 확신할 수 있게 하는 작업작은 단위의 테스트
- 테스트는 가능하면 작은 단위로 쪼개서 집중해서 할 수 있어야 한다.(관심사의 분리 원리 적용)
- 단위 테스트
설계하고 만든 코드가 원래 의도대로 동작하는지 확인하기 위해 작은 단위의 코드에 대해 테스트를 수행하는 것
자동수행 테스트 코드
- 테스트는 자동으로 수행되도록 코드로 만들어지는 것이 중요
- 자동수행 → 반복가능으로 이어진다.
지속적인 개선과 점진적인 개발을 위한 테스트
- 테스트로 검증해서 코드에 대한 확신을 가지고, 그 후에 기능을 추가하는 식으로 점진적인 개발이 가능해진다.
테스트의 효율적인 수행과 결과 관리
- JUnit 프레임워크를 이용해서 테스트를 효율적으로 진행 할 수 있다.
- JUnit의 요구조건
- 테스트하려는 메소드가 public으로 선언되어 있어야 한다.(JUnit5 부터는 없어도 된다)
- @Test를 붙여야 한다.
동일한 결과를 보장하는 테스트
- 항상 일관성 있는 결과가 보장돼야 한다.
- DB에 남아있는 데이터와 같은 외부 환경에 영향을 받지 말아야 한다.
- 테스트를 실행하는 순서를 바꿔도 동일한 결과가 보장되어야 한다.
포괄적인 테스트
- 다양한 상황과 입력 값을 고려하는 포괄적인 테스트를 만드는 것이 좋다.
- 테스트를 작성할 때는 부정적인 케이스를 먼저 만드는 습관이 좋다.
기능설계를 위한 테스트
- 조건, 행위, 결과(given-when-then)
- 기능 설계, 구현, 테스트라는 일반적인 개발 흐름의 기능설계에 해당 하는 부분을 테스트 코드가 담당한다.
- 추가하고 싶은 기능을 테스트 코드로 표현 → 실제 기능을 가진 코드 입력
테스트 주도 개발(TDD)
만들고자 하는 기능의 내용을 담고 있고, 코드의 검증을 할 수 있는 테스트 코드를 먼저 만들고 테스트를 성공하게 해주는 코드를 작성하는 개발 방법론
- TDD에서는 테스트를 작성하고 이를 성공시키는 코드를 만드는 작업의 주기를 짧게 가져가도록 권장한다.
JUnit의 테스트 수행 방식
- 반환값과 파라미터가 없고, @Test가 붙은 테스트 메소드를 찾는다.
- 테스트 클래스의 오브젝트를 만든다.
- @BeforeEach가 붙은 메소드 존재 시 실행
- @Test가 붙은 메소드 호출하고 테스트 결과 저장
- @AfterEach가 붙은 메소드 존재시 실행
- 2~5번 반복
- 테스트 결과를 종합해 출력한다.
테스트 메소드의 컨텍스트 공유
- @ExtendWith
- JUnit4에서는 @RunWith(SpringJUnit4ClassRunner.class) 으로 사용한다.
- JUnit의 프레임워크의 테스트 실행 방법을 확장할 때 사용하는 애노테이션이다.
- 자동으로 만들어줄 애플리케이션 컨텍스트의 설정 위치를 지정한 것이다.
- 애플리케이션 컨텍스트 테스트 개수에 상관없이 한 번만 만들어서 공유한다.
- 스프링 부트를 사용하면 @SpringBootText 하나만 클래스 위에 붙여주면 된다.
DI와 테스트
- 테스트에서도 가능한 한 인터페이스를 사용해서 애플리케이션 코드와 느슨하게 연결해두는 것이 좋다.
- DI를 주입받을 때는 인터페이스를 두고 DI를 적용하는 것이 좋다.
- 클래스의 구현 방식은 바뀌지 않아도 인터페이스를 두고 DI를 적용하게 하면 다른 차원의 서비스 기능을 도입할 수 있다.
학습 테스트
자신이 만들지 않은 프레임워크나 라이브러리 등에 대해서 테스트를 해보는 것
- 다양한 조건에 따른 기능을 손쉽게 확인해 볼 수 있다.
- 학습 테스트 코드를 개발 중에 참고할 수 있다.
- 프레임워크나 제품을 업그레이드할 때 호환성 검증을 도와준다.
- 테스트 작성에 대한 훈련이 된다.
- 조금 더 흥미롭게 기술을 익힐 수 있다.
버그 테스트
코드에 오류가 있을 때 오류를 가장 잘 드러내줄 수 있는 테스트
일단 테스트를 실패하도록 만든 다음 -> 테스트가 성공할 수 있도록 애플리케이션 코드를 수정하는 방법
- 테스트의 완성도를 높여준다.
- 버그의 내용을 명확하게 분석하게 해준다.
- 기술적인 문제를 해결하는데 도움이 된다.
