❗️❗️ 개인적인 해석과 생각이 들어갈 수 있어서 잘못된 정보가 있을 수 있습니다! 잘못된 정보는 지적 부탁드립니다!

---

UserDaoTest의 문제점

• 테스트가 여러 개라면 하나씩 클릭해서 테스트를 실행해야 한다.

• 클래스 1개당 하나의 테스트만 작성할 수 있다.

• main 메서드로 만들어져있다.

  • 클래스에 여러 테스트를 작성할 수 없고 클래스를 찾아다니면서 직접 테스트를 한 개씩 실행해야 한다.

• 수동으로 직접 테스트 결과를 일일이 확인해야 한다.

  • 값을 두 눈으로 확인해야 한다 ex) 결괏값이 제대로 출력됐는지 확인해야한다.

(전에는 실제로 이렇게 클래스 한 개당 1개의 main 메서드에 테스트 코드를 작성했다는 이야기가 있다...)

---

그럼 테스트는 어떻게 짜야할까 ?

• 작은 단위의 테스트
  • 테스트를 하고자 하는 대상이 명확하다면 그 대상에만 집중해서 테스트하도록 하자(독립과 고립) 이렇게 작성한 테스트를 단위 테스트라고 할 수 있다. 단위 테스트에 크기나 범위는 정해진 건 아니지만 될 수 있으면 단위는 작을수록 좋다
• 자동 수행 테스트 코드
  • console에 찍히는 값을 눈으로 비교하면서 하는 테스트에는 실수가 있을 수 있고 매번 모든 테스트를 눈으로 확인하기는 힘들다.
  • 현재는 클래스 한 개 한 개에 직접 main 메서드를 직접 실행해한다 만약 프로젝트의 크기가 커져서 테스트해야 될 것들이 늘어난다면 테스트 검증/실행 시간이 더 오래 걸리며 결국 자주 테스트를 하지 않게 되기 때문에 테스트의 의미가 무색해질 수 있다.
  • 테스트를 자동화해서 언제든지 부담 없이 테스트를 할 수 있도록 작성하자
• 지속적인 개선과 점진적인 개발을 위한 테스트
  • 살충제 패러독스를 방지하고 가독성을 높이기 위함

---

개발자를 위한 테스팅 프레임워크 JUnit

• Junit은 위에서 봤던 main 테스트 메서드가 아니라 좀 더 유연하고 빠르게 테스트를 작성할 수 있다.
  • 클래스 한 개에 @Test를 이용하여 메소드당 각각의 테스트를 (한 번에 혹은 여러 개) 실행이 가능함
  • 여러 가지 검증 메서드들을 제공함assertThat(), assertThrows() ...
  • 같은 클래스에 있지만 각각의 테스트의 독립성을 유지시켜줌 테스트

  ---

테스트 결과의 일관성

• 테스트의 결과는 입력이 같다면 언제든 같은 결과를 반환해야함.
• DB에 insert하는 테스트나 select 테스트를 할시에 만약 테스트한 내용을 DB에서 지우지 않는다면 다음 테스트나 같은 테스트를 다시한번 진행했을때 결과가 다를 수있다. 즉 테스트한 데이터를 지워 줄수있도록 설정을 해야한다. 여기에 대한 방법은 여러가지가 있는데 보통은 테스트가 끝나고 테스트할때 사용한 데이터를 롤백해서 원상복귀시켜놓는 방법이 제일 무난하다(Rollback,Transaction)

---

포괄적인 테스트

• 테스트에 익숙하지 않은 분들이 자주 하는 실수가 있다. 바로 성공하는 테스트만 만드는 것.
• 테스트를 대충 짜서 문제가 있는 경우인데도 성공하는 테스트 코드는 테스트를 하지 않은 것보다 더 위험하다 그 이유는 테스트에 성공했기 때문에 그 문제는 배제하고 넘어가기 때문에 결함을 찾기 더 힘들게 하기 때문이다.
• 항상 테스트를 짤 때는 한 가지의 결과만 검증하는 게 아니라 동등 분할, 경계값 검사 등과같이 여러 케이스를 검증하고 negative 테스트를 먼저 체크하고 작성해서 예외적인 상황을 만들지 않도록 하자

---

TDD

• TDD는 매우 짧은 개발 사이클을 반복하는 개발 프로세스 중 하나이다.
• TDD와 Test를 혼동하는 하는 경우가 있는데 소프트웨어를 개발하는 여러 방법론들 중에 하나이며 Test를 작성한다고 해서 다 TDD는 아니다.
• TDD는 항상 Test를 먼저 작성하고 그다음 서비스 코드를 작성한다고 생각하지만 꼭 그렇지만은 않다 먼저 간단하게 (가짜) 구현한 후에 빠르게 Test를 작성해도 상관없다 TDD는 Test를 항상 전에 만들어야 한다 언제 만들어야 한다는 기준이 있는 건 아니지만 될 수 있으면 빠르게 만드는 게 좋다.

---

테스트 코드 개선

• 모든 테스트에서 사용하는 같은 오브젝트나 (정보) 변수들이 있다면 이를 fidxture고 한다.
• 이런 fidxture를 한곳에 빼서 설정할 수 있다. @Before @BeforEach(assertj) 같은 애노테이션을 사용해서 메서드를 통해 미리 생성해두어 중복도 제거하고 가독성도 높일 수 있다.
• @Before은 각 테스트 실행시마다 알아서 테스트 전에 미리 실행되도록 도와주는 애노테이션이다.

---

테스트 DI

문제

• @Before 과 ApplicationContext를 이용해서 DI를 할 수 있지만 이럴 경우에는 같은 Context가 메서드 개수만큼 생기기 때문에 많은 시간이 소요될 수 있다.

해결법

• 각 테스트에 Context를 공유하자 Context를 설정하는 방법은 여러 가지가 있다. 이러한 설정은 테스트용으로 따로 만들어서 사용하면 된다.
  - @Configuration를 이용하고 AnnotationConfigContextLoader를 이용하는 방법
• xml을 이용한 방법
• 이렇게 Context를 구성하고 주입받을 때는 @Autowired로 주입받아서 사용하면 된다.

단점

• 테스트가 spring에 의존하게 된다.
• 직접 수동으로 DI를 해서 해도 됨 하지만 이는 각각의 trade-off가 있음 만약에 계속 스프링을 사용하고 다른 프레임워크를 사용하지 않는다고 한다면 굳이 수동으로 DI할 필요는 없다고 생각한다.