23.12.04) TIL

이번 심화과제에서 지난번에 만든 프로젝트를 이용해서 테스트 코드를 만들었다.

 

1. 테스트

• 소프트웨어 개발 과정에서 코드의 정확성, 안정성, 및 기능을 확인하고 검증하기 위해 수행되는 활동을 말한다.

2. 단위 테스트(Unit Testing)

 1) 대상: 소프트웨어의 가장 작은 단위인 함수, 메소드, 또는 모듈 등의 개별적인 부분을 테스트합니다.

 2) 목적: 코드의 각 부분이 의도한 대로 동작하는지 확인하고, 변경사항이나 리팩토링으로 인해 예기치 않은 부작용이 없는지 확인합니다.

 3) 장점

• • 빠른 실행 속도: 단위 테스트는 작은 단위의 코드를 테스트하므로 실행 속도가 빠릅니다. 이는 개발자가 빠르게 피드백을 받아 수정할 수 있게 해줍니다.
  • 코드의 안정성: 단위 테스트는 코드의 각 부분이 의도한 대로 동작하는지 확인하므로 코드의 안정성을 높일 수 있습니다.
  • 리팩토링 지원: 코드를 리팩토링할 때 단위 테스트가 있다면, 리팩토링 후에도 코드의 기능이 유지되었는지 빠르게 확인할 수 있습니다.
  • 문서화 역할: 단위 테스트 코드는 코드의 사용법 및 동작을 설명하는 추가적인 문서 역할을 합니다.

 4) 단점

• • 전체 시스템 동작 미포함: 단위 테스트는 개별 모듈 또는 메소드에 집중되기 때문에 전체 시스템의 상호 작용을 확인하지 못할 수 있습니다.
  • 통합 오류 미감지: 단위 테스트는 모듈이 잘 동작한다고 가정하고 진행되기 때문에 통합에서 발생하는 오류를 미리 감지하기 어렵습니다.

 5) 단위테스트는 레어별로 나누어서 한다. 왜?

• 레이어별로 테스트를 나누는 이유는 소프트웨어를 더욱 효과적으로 테스트하고 관리하기 위함입니다. 각 레이어는 특정한 책임과 역할을 담당하며, 각 레이어별로 테스트를 나누는 것은 다음과 같은 이점을 제공합니다:
  • 모듈화 및 유지보수성 향상:
    • 각 레이어는 특정한 기능 또는 책임을 수행하므로, 해당 레이어의 테스트를 나누면 코드가 모듈화되어 유지보수가 더욱 용이해집니다.
    • 특정 레이어의 변경이 해당 레이어에만 영향을 미치게 되므로, 다른 레이어의 코드를 건드리지 않고도 변경이 가능합니다.
  • 안정성 확보:
    • 레이어별 테스트는 각 레이어의 동작이 올바르게 이루어지는지 확인하여 전체 시스템의 안정성을 보장합니다.
    • 특히 단위 테스트를 통해 각 레이어의 기능을 견고하게 테스트함으로써, 예상치 못한 버그를 최소화하고 코드의 신뢰성을 높일 수 있습니다.
  • 테스트의 용이성:
    • 레이어별로 테스트를 나누면 특정 레이어에 초점을 맞춘 테스트를 작성할 수 있습니다.
    • 단위 테스트는 특정 모듈이나 함수의 동작을 검증하며, 통합 테스트에서는 각 레이어 간 상호 작용을 테스트할 수 있습니다.
  • 코드의 재사용성:
    • 각 레이어가 독립적으로 테스트되기 때문에, 해당 레이어의 코드는 다른 프로젝트나 모듈에서도 재사용될 수 있습니다.
    • 테스트 가능한 코드는 더 유연하게 재사용될 수 있습니다.
  • 테스트의 병렬 실행:
    • 레이어별로 테스트를 나누면 각 레이어의 테스트를 병렬로 실행할 수 있습니다.
    • 병렬 실행은 테스트 수행 시간을 단축하고 CI/CD (지속적 통합/지속적 배포) 파이프라인을 최적화하는 데 도움이 됩니다.

 6) 각 레이어(Controller, Service, Repository)에서 하는 테스트

• 컨트롤러 테스트
  • 컨트롤러 테스트는 주로 해당 컨트롤러가 원활하게 동작하는지, 요청을 제대로 처리하고 응답을 반환하는지 등을 검증합니다.
  • 테스트 유형
    1. HTTP 요청 테스트: 웹 애플리케이션에서 사용되는 경우, 각각의 엔드포인트에 대한 HTTP 요청을 시뮬레이션하여 테스트합니다.
    2. 비즈니스 로직 호출 테스트: 서비스와의 상호 작용이 올바른지 확인하기 위해 비즈니스 로직을 호출하는 부분을 테스트합니다.
    3. 모의 객체(Mock 객체) 사용: 의존하는 서비스나 레포지토리 등을 모의 객체로 대체하여 테스트합니다.
• 서비스 테스트
  • 서비스 테스트는 비즈니스 로직이 제대로 동작하며, 서비스가 예외 상황에 대응할 수 있는지를 검증합니다.
  • 테스트 유형
    1. 비즈니스 로직 테스트: 서비스가 수행하는 각 비즈니스 로직에 대한 테스트를 작성합니다.
    2. 트랜잭션 테스트: 트랜잭션 처리가 올바르게 이루어지는지 확인합니다.
    3. 예외 처리 테스트: 서비스가 예외 상황에 대한 적절한 예외를 던지고 처리하는지 검증합니다.
• 레포지토리 테스트
  • 레포지토리 테스트는 데이터베이스와의 상호 작용이 올바르게 이루어지는지를 검증합니다.
  • 테스트 유형
    1. CRUD 작업 테스트: 데이터를 생성, 읽기, 수정, 삭제하는 작업에 대한 테스트를 작성합니다.
    2. 쿼리 메소드 테스트: 사용자가 정의한 쿼리 메소드가 올바르게 동작하는지 테스트합니다.
    3. 트랜잭션 테스트: 트랜잭션 처리가 올바르게 이루어지는지 확인합니다.

3. 통합 테스트(Integration Testing)

 1) 대상: 다수의 모듈 또는 컴포넌트가 함께 동작하는지, 상호 작용하는지 테스트합니다.

 2) 목적: 다양한 모듈 간의 통합에서 발생할 수 있는 문제를 식별하고, 전반적인 시스템이 예상대로 작동하는지 확인합니다.

 3) 장점

• • 전체 시스템 테스트: 통합 테스트는 다양한 모듈 또는 컴포넌트 간의 상호 작용을 테스트하므로 전체 시스템 동작을 확인할 수 있습니다.
  • 모듈 간 상호 작용 확인: 통합 테스트는 다양한 모듈이 서로 잘 상호 작용하는지 확인할 수 있습니다.

 4) 단점

• • 느린 실행 속도: 통합 테스트는 전체 시스템을 테스트하므로 실행 속도가 단위 테스트에 비해 느릴 수 있습니다.
  • 디버깅 어려움: 오류 발생 시 해당 오류가 어느 모듈에서 발생했는지 찾기 어려울 수 있습니다.
  • 의존성 관리 어려움: 통합 테스트에서는 다양한 모듈이 상호 작용하기 때문에 의존성을 관리하는데 어려움이 있을 수 있습니다.

4. 이번 과제를 통해서...

컨트롤러 테스트는 손도 못 됐을 정도로 어려운 과제였다. 서비스와 dto, entity 쪽은 일단 만들긴 했으나 과제 해설영상을 보니 미흡한 부분이 많이 보였다. 테스트 코드가 앞으로 꼭 필요하기 때문에 테스트 코드에 대해 공부를 더 해야겠다.