총 정리

1. 테스트는 왜 필요할까?

• 테스트를 아예 작성하지 않는 경우
  빠르게 변화하는 소프트웨어의 품질을 일정 수준 이상으로 가져가기 어렵다.

• 테스트 코드를 작성하더라도 테스트 코드 자체가 병목이 되는 경우
  테스트 코드를 작성하더라도 테스트 코드를 엉망으로 작성하면 잘못된 검증을 하고도 올바르다고 인식을 하고 넘어가는 문제가 발생할 수 있다.

=> 테스트가 왜 필요한지에 대해 인지가 우선이 되어야 하고 그 다음에 기술이나 방법론을 학습한다.

[박우빈, Practical Testing #1]테스트는 왜 필요할까? 정리 보러가기

2. 단위 테스트

• 테스트 도구 JUnit
• 단위 테스트란 작은 코드 단위를 독립적으로 테스트하는 것.
• 테스트 하기 어려운 영역을 상위 계층으로 분리하여 테스트 가능한 영역의 범위를 넓히고 테스트가 용이한 구조로 설계를 할 수 있다.

[박우빈, Practical Testing #2]단위테스트 정리 보러가기

3. TDD

• TDD란 프로덕션 코드보다 테스트 코드를 먼저 작성하여 테스트가 구현 과정을 주도하도록 하는 방법론 중 하나.
• 레드 그린 리팩토링
• TDD의 장점
  • 쉽게 발견하기 어려운 엣지 케이스를 놓치지 않게 해준다.
  • 테스트 코드가 보장해주므로 과감한 리팩토링이 가능하다.
  • 클라이언트 관점에서 코드에 피드백을 줄 수 있다.

[박우빈, Practical Testing #3]TDD: Test Driven Development 정리 보러가기

4. 테스트는 문서다.

• 테스트 코드는 문서의 역할을 한다.
• 우리는 항상 팀으로 일하기 때문에 내가 했던 고민의 결과물을 팀 차원의 자원으로 승격시켜 팀을 위한 자산으로 만들 수 있다.
• DisplayName 신중하게 작성하기.
• BDD : 행동 주도 개발. 함수 단위의 테스트에 집중하기보다, 시나리오에 기반한 테스트케이스(TC) 자체에 집중하여 테스트한다.

[박우빈, Practical Testing #4]테스트는 [ ]다. 정리 보러가기

5. Spring & JPA 기반 테스트

• 레이어드 아키텍처 : 레이어별 관심사가 다르기 때문에 레이어를 분리하고 그에 맞추어 테스트가 필요하다.
• 리포지토리와 서비스는 통합 테스트로 실습.
• 컨트롤러는 하위 레이어들을 목킹 처리하여 단위 테스트 느낌으로 실습.

[박우빈, Practical Testing #5]Spring & JPA 기반 테스트 정리 보러가기

6. Mock을 대하는 자세

• 테스트 더블 : 영화 제작 시 배우 대신 위험한 장면을 대신 연기하는 스턴트 더블에서 유래된 개념이다. 소프트웨어 테스트에서도 비슷하게, 실제 객체의 일부 또는 전체 기능을 대신 수행하는 테스트 대역을 사용한다.
• 스터빙 : 실제 동작을 수행하지 않고 특정 입력에 대해 원하는 출력을 정의하여 단순히 테스트에서 필요한 값을 반환하도록 동작을 정의하는 것
• Mokito 라이브러리의 @Mock, @Spy, @InjectMocks등 순수 Mokito를 사용하여 테스트
• BDDMokito : BDD 스타일로 테스트를 작성할 수 있도록 지원하는 Mockito의 확장 기능이다.

[박우빈, Practical Testing #6]Mock을 마주하는 자세 정리 보러가기

7. 더 나은 테스트를 작성하기 위한 구체적 조언

[박우빈, Practical Testing #7]더 나은 테스트를 작성하기 위한 구체적 조언 보러가기

8. Appendix

• 학습 테스트 : 잘 모르는 기능, 라이브러리, 프레임워크를 학습하기 위해 작성하는 테스트
• 테스트 코드를 통한 문서 자동화 도구 중 하나인 Spring Rest Docs

[박우빈, Practical Testing #8]Appendix 보러가기

테스트는 귀찮은 작업이다. 테스트를 작성하는 기술이나 방법론보다도 테스트를 왜 작성해야 하는지를 명확히 인지하고 있어야 귀찮음을 이기고 테스트를 작성할 수 있기 때문에 테스트 작성의 중요성을 인지하는게 훨씬 중요하다.

우리는 한정된 시간 안에서 무언가를 만들어 내야 된다. 한정된 시간 내에서 우리가 올바른 테스트를 작성하려면 어떻게 해야할까?
테스트 케이스를 추론하고 구체화 하는 연습이 필요하다.
어떤 케이스가 있어야 내가 지금 작성하려는 프로덕션 코드가 더 단단해질까 어떤 케이스로 검증하면 좋을까 고민을 해보고 케이스들이 리스트업이 됐다면 그 이후로는 빠르고 정확하게 문서로써의 테스트를 작성하고 프로덕션 코드를 그에 맞춰 구현을 하는 것이다.

테스트 코드를 도구라고 치면 최적의 상황을 판별하고 그에 맞게 도구를 빠르게 사용할 수 있어야 한다.
이 도구들을 많이 활용해보고 효율적으로 사용하기 위해선 많이 사용해봐야 한다.

타협 하지 않는 마음이 제일 중요하다. 가까이 보면 느리지만 멀리 보면 가장 빠르다라는 것이 테스트를 작성하기 귀찮은 마음과 시간적 압박이 있더라도 지금 시간을 조금 더 투자해 테스트 코드를 작성하여 미래의 수많은 시간을 아낄 수 있다.

---

출처 - 박우빈, Practical Testing: 실용적인 테스트 가이드
이 블로그에 포함된 모든 코드와 이미지는 원작자이신 박우빈 강사님의 저작권에 귀속됩니다.