개발 방법론 TDD

Q. TDD에 대해서 설명해주세요.

A. TDD란 테스트 주도 개발 (Test-Driven Development)의 약자로 코드를 작성하기 전에 먼저 테스트 코드를 작성하는 개발 방법론입니다. 보통 TDD는 세 가지 단계로 이루어 집니다.

Red(실패하는 테스트 작성): 먼저 테스트 코드를 작성하고, 해당 테스트가 실패하는 것을 확인합니다. 이 단계에서는 아직 구현 코드가 없기 때문에 테스트는 당연히 실패합니다.
Green(테스트를 통과하도록 구현): 테스트를 통과할 수 있도록 최소한의 코드를 작성합니다. 이 단계에서는 기능 구현보다는 테스트를 통과하는 데 초점을 맞춥니다.
Refactor(코드 리팩토링): 테스트를 통과한 코드를 리팩토링하여 중복을 제거하고, 가독성이나 유지보수성을 높이는 작업을 합니다. 리팩토링 후에도 테스트는 여전히 통과해야 합니다. 이 과정을 반복하면서 점진적으로 기능을 완성해 나가는 방식입니다. TDD의 장점으로는 코드 품질 개선, 버그 예방, 리팩토링 용이성이 있으며, 개발 초기 단계부터 테스트가 포함되므로 테스트 커버리지를 자연스럽게 높일 수 있습니다. 하지만, 개발 속도가 느려질 수 있다는 단점도 있으며, TDD가 모든 상황에서 적합하지 않을 수 있습니다. 특히 UI 개발이나 복잡한 비즈니스 로직이 있는 경우에는 TDD를 적용하기 어려울 수 있습니다.

Q. 그렇다면 테스트에는 어떠한 테스트들이 있나요?

A. 테스트는 개발 과정에서 다양한 수준과 목적에 따라 나뉩니다. 가장 기본적인 테스트부터

Unit Test(단위 테스트)는 가장 작은 단위, 예를 들어 함수나 메서드 같은 개별 코드 조각이 올바르게 동작 하는지 확인하는 테스트입니다. 외부 의존성 없이 독립적으로 해당 기능이 정상적으로 작동하는지 검증합니다.
Intergration Test(통합 테스트)는 단위들이 서로 연동되었을 때 잘 작동하는지 확인하는 테스트입니다. 예를 들어, 서비스 계층이 데이터베이스와 연동되어 데이터를 제대로 주고받는지 확인하는 것이 통합 테스트의 목적입니다.
Functional Test(기능 테스트)는 시스템의 각 기능이 사용자 요구 사항을 충족하는지 테스트하는 것으로, 보통 End-to-End(엔드투엔드)로 실제 사용 시나리오를 따라가며 전체 시스템의 동작을 확인하는 방식입니다.
Regression Test(회귀 테스트)는 기존 기능이 새로운 코드 변경에도 영향을 받지 않고 잘 작동하는지 확인하는 테스트입니다. 코드가 수정될 때마다 이전에 잘 작동하던 기능에 문제가 생길 수 있는데, 이를 미리 방지하기 위해 사용합니다.
Load Test(부하 테스트)는 시스템이 고부하 상황에서 얼마나 잘 견디는지 테스트하는 것으로, 예를 들어 동시 접속자가 많을 때 서버가 안정적으로 응답하는지를 확인하는 테스트입니다.

Q. 그렇다면 모든 코드에 테스트 코드를 작성하는 것이 좋을까요?

A. 모든 코드에 테스트 코드를 작성하는 것이 이상적이긴 하지만, 현실적으로는 꼭 그렇지 않습니다. 테스트 코드를 작성할 때는 효율성과 유지보수성을 고려해야 하며, 어떤 코드에 테스트가 필요한지 우선순위를 정하는 것이 중요합니다. 다음과 같은 이유로 모든 코드에 테스트를 작성하는 것이 항상 좋은 전략은 아닙니다

비즈니스 로직이 없는 단순 코드: 단순히 getter/setter 메서드나 상수 값을 반환하는 메서드처럼 테스트할 필요가 없는 단순한 코드에 대해 테스트를 작성하는 것은 시간 낭비일 수 있습니다.
자주 변경되는 코드: 개발 중이거나 자주 변경될 가능성이 높은 코드에 대한 테스트는 작성과 유지보수 비용이 높아질 수 있습니다. 이런 경우 안정된 부분이나 핵심 로직에 테스트를 집중하는 것이 효율적입니다.
외부 시스템과 연동된 코드: 외부 API나 DB에 의존하는 코드에 대해 테스트 코드를 작성할 때는 모든 외부 연동을 일일이 테스트하기보다, Mocking이나 Stub을 사용해 단위 테스트에 집중하는 것이 더 효과적일 수 있습니다. 따라서 핵심 비즈니스 로직, 복잡한 알고리즘, 자주 사용하는 유틸리티 함수와 같이 코드의 안정성이 중요한 부분에 우선적으로 테스트를 작성하는 것이 좋습니다. 모든 코드에 테스트를 작성하기보다는 테스트의 효용성을 극대화할 수 있는 부분에 집중하는 것이 더 현실적이고 효과적인 접근입니다.

Previous채팅 아키텍처 설계 NextJIT & AOT 컴파일

Last updated 7 months ago

Q. TDD에 대해서 설명해주세요.

Red(실패하는 테스트 작성): 먼저 테스트 코드를 작성하고, 해당 테스트가 실패하는 것을 확인합니다. 이 단계에서는 아직 구현 코드가 없기 때문에 테스트는 당연히 실패합니다.

Green(테스트를 통과하도록 구현): 테스트를 통과할 수 있도록 최소한의 코드를 작성합니다. 이 단계에서는 기능 구현보다는 테스트를 통과하는 데 초점을 맞춥니다.

Refactor(코드 리팩토링): 테스트를 통과한 코드를 리팩토링하여 중복을 제거하고, 가독성이나 유지보수성을 높이는 작업을 합니다. 리팩토링 후에도 테스트는 여전히 통과해야 합니다. 이 과정을 반복하면서 점진적으로 기능을 완성해 나가는 방식입니다. TDD의 장점으로는 코드 품질 개선, 버그 예방, 리팩토링 용이성이 있으며, 개발 초기 단계부터 테스트가 포함되므로 테스트 커버리지를 자연스럽게 높일 수 있습니다. 하지만, 개발 속도가 느려질 수 있다는 단점도 있으며, TDD가 모든 상황에서 적합하지 않을 수 있습니다. 특히 UI 개발이나 복잡한 비즈니스 로직이 있는 경우에는 TDD를 적용하기 어려울 수 있습니다.

Q. 그렇다면 테스트에는 어떠한 테스트들이 있나요?

A. 테스트는 개발 과정에서 다양한 수준과 목적에 따라 나뉩니다. 가장 기본적인 테스트부터

Unit Test(단위 테스트)는 가장 작은 단위, 예를 들어 함수나 메서드 같은 개별 코드 조각이 올바르게 동작 하는지 확인하는 테스트입니다. 외부 의존성 없이 독립적으로 해당 기능이 정상적으로 작동하는지 검증합니다.

Intergration Test(통합 테스트)는 단위들이 서로 연동되었을 때 잘 작동하는지 확인하는 테스트입니다. 예를 들어, 서비스 계층이 데이터베이스와 연동되어 데이터를 제대로 주고받는지 확인하는 것이 통합 테스트의 목적입니다.

Functional Test(기능 테스트)는 시스템의 각 기능이 사용자 요구 사항을 충족하는지 테스트하는 것으로, 보통 End-to-End(엔드투엔드)로 실제 사용 시나리오를 따라가며 전체 시스템의 동작을 확인하는 방식입니다.

Regression Test(회귀 테스트)는 기존 기능이 새로운 코드 변경에도 영향을 받지 않고 잘 작동하는지 확인하는 테스트입니다. 코드가 수정될 때마다 이전에 잘 작동하던 기능에 문제가 생길 수 있는데, 이를 미리 방지하기 위해 사용합니다.

Load Test(부하 테스트)는 시스템이 고부하 상황에서 얼마나 잘 견디는지 테스트하는 것으로, 예를 들어 동시 접속자가 많을 때 서버가 안정적으로 응답하는지를 확인하는 테스트입니다.

Q. 그렇다면 모든 코드에 테스트 코드를 작성하는 것이 좋을까요?

비즈니스 로직이 없는 단순 코드: 단순히 getter/setter 메서드나 상수 값을 반환하는 메서드처럼 테스트할 필요가 없는 단순한 코드에 대해 테스트를 작성하는 것은 시간 낭비일 수 있습니다.

자주 변경되는 코드: 개발 중이거나 자주 변경될 가능성이 높은 코드에 대한 테스트는 작성과 유지보수 비용이 높아질 수 있습니다. 이런 경우 안정된 부분이나 핵심 로직에 테스트를 집중하는 것이 효율적입니다.

외부 시스템과 연동된 코드: 외부 API나 DB에 의존하는 코드에 대해 테스트 코드를 작성할 때는 모든 외부 연동을 일일이 테스트하기보다, Mocking이나 Stub을 사용해 단위 테스트에 집중하는 것이 더 효과적일 수 있습니다. 따라서 핵심 비즈니스 로직, 복잡한 알고리즘, 자주 사용하는 유틸리티 함수와 같이 코드의 안정성이 중요한 부분에 우선적으로 테스트를 작성하는 것이 좋습니다. 모든 코드에 테스트를 작성하기보다는 테스트의 효용성을 극대화할 수 있는 부분에 집중하는 것이 더 현실적이고 효과적인 접근입니다.