테스트 (TDD / BDD) 면접 질문

단위 테스트는 애플리케이션을 구성하는 가장 작은 단위, 예를 들어 함수나 메서드 하나를 독립적으로 떼어내서 검증하는 테스트입니다.

단위 테스트가 필요한 이유는 크게 세 가지입니다. 첫째, 코드의 특정 부분이 예상대로 정확하게 동작하는지 빠르게 확인할 수 있습니다. 둘째, 개발 초기 단계에서 버그를 발견하여 수정 비용을 줄일 수 있습니다. 셋째, 코드 변경 후에도 기존 기능이 잘 작동하는지 확인하는 회귀 테스트를 자동화하여 코드 품질을 유지하는 데 도움이 됩니다. 단위 테스트를 통해 코드에 대한 자신감을 높이고 유지보수성을 향상시킬 수 있습니다.

단위 테스트를 작성하면 여러 가지 이점이 있습니다.

첫째, 버그를 조기에 발견할 수 있습니다. 작은 단위로 코드를 테스트하기 때문에 문제 발생 지점을 빠르게 찾아 수정할 수 있습니다.

둘째, 코드 품질이 향상됩니다. 테스트를 통과하는 코드를 작성하기 위해 더 꼼꼼하게 설계하고 구현하게 되므로 자연스럽게 코드의 가독성과 유지보수성이 높아집니다.

셋째, 리팩토링이 용이해집니다. 기존 기능이 제대로 동작하는지 단위 테스트를 통해 빠르게 확인할 수 있기 때문에 안심하고 코드 구조를 개선할 수 있습니다. 테스트 코드가 일종의 안전망 역할을 하는 것이죠.

마지막으로, 단위 테스트는 개발 속도 향상에도 기여합니다. 초기에 버그를 잡고, 리팩토링을 쉽게 할 수 있게 해주므로 전체적인 개발 생산성을 높일 수 있습니다.

통합 테스트는 여러 모듈이나 컴포넌트들이 함께 작동할 때, 그 상호작용이 제대로 이루어지는지 확인하는 테스트입니다. 예를 들어, A 모듈이 B 모듈에 데이터를 전달하고, B 모듈이 그 데이터를 처리하는 과정을 테스트하는 것이죠.

단위 테스트는 개별 모듈이나 함수가 예상대로 동작하는지 검증하는 데 집중합니다. 각 모듈을 격리된 환경에서 테스트하는 반면, 통합 테스트는 모듈 간의 인터페이스와 데이터 흐름을 검증하여 전체 시스템이 올바르게 작동하는지 확인하는 데 목적이 있습니다. 단위 테스트가 개별 부품을 검사하는 것이라면, 통합 테스트는 조립된 제품이 제대로 작동하는지 확인하는 것과 같습니다.

TDD는 테스트 주도 개발(Test-Driven Development)의 약자로, 개발 전에 테스트 코드를 먼저 작성하는 개발 방법론입니다. 코드를 작성하기 전에 무엇을 만들어야 하는지 명확하게 정의하는 데 도움이 됩니다.

TDD의 기본적인 개발 주기는 Red-Green-Refactor로 알려져 있습니다.

1. Red (실패): 먼저 실패하는 테스트 코드를 작성합니다. 아직 구현 코드가 없기 때문에 당연히 실패해야 합니다. 이 단계를 통해 요구사항을 명확히 이해하고 테스트가 올바르게 작동하는지 확인합니다.

2. Green (성공): 작성한 테스트를 통과할 수 있을 만큼의 최소한의 코드를 작성합니다. 완벽한 코드를 만드는 것이 아니라, 테스트를 통과하는 데 집중합니다.

3. Refactor (리팩토링): 코드를 정리하고 개선합니다. 중복을 제거하고, 가독성을 높이며, 디자인을 개선합니다. 이 단계에서는 기존 테스트를 통과하는지 확인하면서 코드를 변경합니다.

이 주기를 반복하면서 점진적으로 코드를 완성해 나갑니다.

TDD를 적용했을 때 얻을 수 있는 주요 이점은 크게 네 가지 정도로 말씀드릴 수 있습니다.

첫째, 코드 품질 향상입니다. 테스트를 먼저 작성하기 때문에 자연스럽게 테스트하기 쉬운 코드를 만들게 되고, 이는 코드의 결합도를 낮추고 응집도를 높이는 데 도움이 됩니다.

둘째, 높은 테스트 커버리지를 확보할 수 있습니다. 개발 전에 테스트 케이스를 정의하므로, 개발 후 테스트를 작성하는 방식보다 더 꼼꼼하게 코드를 검증할 수 있습니다.

셋째, 디버깅 시간 감소입니다. 작은 기능 단위로 테스트를 진행하고, 문제가 발생하면 즉시 수정하므로 전체적인 디버깅 시간을 줄일 수 있습니다.

마지막으로, 설계 개선 효과가 있습니다. 테스트를 통과하는 코드를 만들기 위해 고민하는 과정에서 더 나은 설계 방안을 찾게 되고, 요구사항을 더 명확하게 이해하게 됩니다. 이러한 과정을 통해 코드의 유지보수성이 향상됩니다.

BDD는 Behavior-Driven Development, 즉 행위 주도 개발을 의미합니다. 사용자 스토리 기반으로 개발하며, "Given-When-Then" 형태의 시나리오를 작성하여 개발, 테스트, 그리고 비즈니스 관계자 간의 이해를 돕는 것이 특징입니다.

TDD(Test-Driven Development)와 비교했을 때, TDD는 개발자 관점에서 단위 테스트를 먼저 작성하고 코드를 구현하는 방식입니다. 반면 BDD는 비즈니스 관점에서 사용자 행동을 먼저 정의하고 이를 기반으로 테스트 케이스와 코드를 개발합니다. 따라서 BDD는 요구사항 정의 단계에서부터 모든 관계자가 참여하여 더욱 명확하고 공유된 이해를 바탕으로 개발을 진행할 수 있도록 돕습니다.

테스트 더블은 테스트를 진행할 때, 테스트 대상 객체가 의존하는 객체를 대신하는 가짜 객체입니다. 마치 영화 촬영장에서 배우를 대신하는 스턴트맨과 비슷하다고 생각하시면 됩니다.

테스트 더블을 사용하는 이유는 크게 두 가지입니다. 첫째, 테스트 격리를 위해서입니다. 외부 시스템이나 데이터베이스처럼 불안정하거나 느린 의존성으로부터 테스트를 분리하여, 테스트가 항상 빠르고 예측 가능한 결과를 내도록 합니다. 둘째, 테스트 용이성을 높이기 위해서입니다. 아직 구현되지 않았거나 복잡한 의존성을 가진 객체를 테스트 더블로 대체하여, 테스트를 더 쉽게 작성하고 실행할 수 있습니다.

예를 들어, 데이터베이스에 접근하는 코드를 테스트할 때, 실제 데이터베이스 대신 메모리 기반의 테스트 더블을 사용하면 훨씬 빠르고 안정적인 테스트가 가능합니다. 모의 객체(Mock Object)는 테스트 더블의 한 종류이며, 특정 메서드가 호출되었는지, 어떤 인자로 호출되었는지 등을 검증하는 데 사용됩니다.

TDD의 Red-Green-Refactor 사이클은 견고한 코드를 만들기 위한 핵심적인 방법론입니다.

Red 단계에서는 실패하는 테스트 케이스를 먼저 작성합니다. 아직 구현되지 않은 기능을 명확하게 정의하고, 무엇을 테스트해야 하는지 구체화하는 단계입니다. 이 단계가 중요한 이유는 요구사항을 명확히 하고, 테스트 가능한 코드를 설계하도록 강제하기 때문입니다.

Green 단계에서는 Red 단계에서 실패한 테스트를 통과시키는 최소한의 코드를 작성합니다. 완벽한 코드를 만드는 것보다 테스트를 통과하는 데 집중하며, 빠른 피드백을 얻는 것이 목표입니다.

Refactor 단계에서는 코드의 가독성을 높이고, 중복을 제거하며, 설계를 개선합니다. 테스트를 통과하는 상태를 유지하면서 코드의 품질을 향상시키는 단계입니다. 이 단계를 통해 코드의 유지보수성을 높이고, 장기적인 관점에서 개발 효율성을 향상시킬 수 있습니다.

TDD를 프로젝트에 적용했을 때 얻을 수 있는 주요 이점은 코드 품질 향상과 설계 개선입니다. 테스트를 먼저 작성하면서 자연스럽게 테스트하기 쉬운 코드를 만들게 되고, 이는 곧 모듈화된 깔끔한 설계로 이어집니다. 또한, 버그를 초기에 발견하고 리팩토링을 더욱 안전하게 할 수 있다는 장점도 있습니다. 일종의 살아있는 문서 역할도 수행하죠.

하지만 TDD에는 어려움도 따릅니다. 처음 TDD를 접하는 개발자는 학습 곡선을 경험하게 되고, 테스트 코드 작성에 시간을 투자해야 하므로 초기 개발 속도가 느려질 수 있습니다. 또, 완벽한 테스트를 작성하는 데 집중하다 보면 오히려 개발이 지연될 수도 있습니다. 따라서 프로젝트 상황에 맞춰 TDD를 적절히 적용하는 것이 중요합니다.

BDD는 TDD에서 발전된 형태로, TDD가 개발자 관점에서 '어떻게' 구현할지 검증하는 데 집중한다면, BDD는 '무엇'을 왜 구현해야 하는지에 대한 비즈니스 가치와 사용자 행동에 초점을 맞춥니다.

가장 큰 차이점은 BDD가 행위 명세에 기반한다는 점입니다. 시나리오 기반으로 작성된 명세는 비즈니스 이해관계자, 개발자, 테스터 간의 협업을 촉진하고, 모두가 동일한 이해를 갖도록 돕습니다.

BDD가 강조하는 주요 가치는 다음과 같습니다. 첫째, 이해관계자 간의 협업을 통해 요구사항을 명확히 정의합니다. 둘째, 공통의 언어를 사용하여 커뮤니케이션 오류를 줄입니다. 셋째, 자동화된 테스트를 통해 시스템의 동작을 검증하고, 변경에 대한 안정성을 확보합니다. 즉, BDD는 단순히 테스트를 넘어, 개발 프로세스 전반에 걸쳐 비즈니스 가치를 반영하는 데 목적이 있습니다.

BDD(Behavior-Driven Development) 시나리오 작성 시 사용되는 Given-When-Then 구조는 테스트 케이스를 명확하게 정의하고, 이해 관계자 간의 소통을 원활하게 하는 데 핵심적인 역할을 합니다.

Given은 특정 시나리오가 시작되기 위한 초기 상태, 즉 전제 조건을 설정합니다. When은 시스템에 가해지는 특정 행동이나 이벤트를 설명합니다. Then은 When 액션 이후 예상되는 결과를 명시합니다.

이 구조는 비기술적인 이해 관계자도 시나리오를 쉽게 이해할 수 있도록 돕습니다. 예를 들어, "Given 잔액이 10,000원인 계좌가 있고, When 5,000원을 출금하면, Then 잔액은 5,000원이 되어야 한다"와 같이 표현하면 누구나 시스템의 동작을 명확하게 파악할 수 있습니다.

또한, Given-When-Then 구조는 자동화 테스트 코드를 작성하기 용이하게 만들어 개발자와 테스터 간의 협업을 증진시키고, 요구사항을 명확하게 정의하여 개발 과정에서의 오해를 줄이는 데 기여합니다.

단위 테스트에서 Mock이나 Stub 객체를 사용하는 이유는 주로 외부 의존성을 격리하기 위해서입니다. 실제 객체를 사용하면 데이터베이스, 네트워크 통신 등 통제하기 어려운 요소에 의존하게 되어 테스트가 불안정해지고 느려질 수 있습니다.

Mock이나 Stub은 이러한 의존성을 가짜 객체로 대체하여 테스트 대상 코드에 집중하고, 예측 가능한 결과를 얻도록 도와줍니다. 예를 들어, 데이터베이스에 접근하는 코드를 테스트할 때 Mock 객체를 사용하여 데이터베이스 연결 없이 미리 정의된 데이터를 반환하도록 설정할 수 있습니다.

반면, 실제 객체를 사용하는 경우는 통합 테스트나 인수 테스트처럼 전체 시스템의 동작을 검증해야 할 때 유용합니다. 단위 테스트에서는 격리를 통해 테스트의 독립성과 속도를 높이는 것이 중요하기 때문에 Mock이나 Stub을 사용하는 것이 일반적입니다.

TDD/BDD 관점에서 테스트 피라미드를 생각하면 각 테스트의 비중과 역할을 이해하기 쉽습니다.

단위 테스트는 가장 많은 비중을 차지해야 합니다. TDD에서는 코드를 작성하기 전에 테스트를 먼저 작성하여 코드의 설계와 동작을 명확히 정의합니다. BDD에서는 "Given-When-Then" 형식으로 비즈니스 로직을 검증하는 테스트를 작성합니다. 핵심은 각 단위가 격리된 상태에서 예상대로 동작하는지 확인하는 것입니다.

통합 테스트는 단위 테스트보다는 적은 비중을 가져야 합니다. 단위 테스트를 통과한 모듈들이 서로 연동될 때 인터페이스가 제대로 작동하는지 검증합니다. 예를 들어, API 호출이나 데이터베이스 연동 등이 제대로 이루어지는지 확인합니다.

E2E 테스트는 가장 적은 비중을 차지해야 합니다. 실제 사용자의 시나리오를 따라 전체 시스템이 예상대로 동작하는지 검증합니다. 브라우저를 사용하여 UI를 테스트하거나, API를 호출하여 전체 흐름을 테스트하는 방식이 있습니다. E2E 테스트는 비용이 많이 들기 때문에 핵심적인 시나리오에 집중하는 것이 좋습니다.

테스트 더블은 테스트 대상 객체의 의존성을 대체하는 객체입니다. 테스트 격리를 통해 테스트를 용이하게 만들어주죠. 종류는 크게 다섯 가지가 있습니다.

• Dummy: 단순히 객체 전달을 위해 존재하며, 실제로 사용되지는 않습니다. 예를 들어, 생성자에 객체를 넘겨줘야 하지만 테스트에서 필요 없는 경우에 사용합니다.

• Fake: 실제 동작을 흉내 내지만, 단순화된 형태로 구현됩니다. 예를 들어, 실제 데이터베이스 대신 메모리 데이터베이스를 사용하는 경우가 있습니다.

• Stub: 미리 정의된 결과를 반환하도록 설정된 객체입니다. 특정 입력에 대해 항상 같은 출력을 보장해야 할 때 유용합니다. 예를 들어, 외부 API 호출 결과를 미리 정의된 값으로 대체할 수 있습니다.

• Spy: Stub과 유사하지만, 호출 정보를 기록합니다. 호출 횟수나 인자 등을 검증할 때 사용합니다. 예를 들어, 특정 함수가 몇 번 호출되었는지 확인할 수 있습니다.

• Mock: Spy보다 더 강력하며, 행위 검증에 특화되어 있습니다. 예상되는 상호작용을 미리 정의하고, 실제로 그 상호작용이 발생하는지 검증합니다. 예를 들어, 특정 메서드가 특정 인자로 호출되는지 확인할 수 있습니다.

TDD/BDD는 시스템 아키텍처 설계에 깊숙이 관여하여 모듈성, 응집도, 결합도에 긍정적인 영향을 미칩니다.

테스트를 먼저 작성하기 때문에, 자연스럽게 각 모듈이 독립적으로 테스트 가능하도록 설계하게 됩니다. 이는 곧 모듈성 향상으로 이어집니다. 또한, 각 모듈이 하나의 책임만 갖도록 집중하게 되므로 높은 응집도를 유지하게 됩니다.

테스트를 통과하기 위해 인터페이스를 명확하게 정의하고, 불필요한 의존성을 줄이려고 노력하게 되므로 결합도는 낮아집니다. 결과적으로 코드를 변경하거나 리팩토링할 때 다른 부분에 미치는 영향이 적어 유지보수성이 향상됩니다.

실제 프로젝트에서 TDD를 적용했을 때, 처음에는 시간이 더 걸리는 듯했지만, 결국에는 더 안정적이고 유지보수하기 쉬운 시스템을 구축할 수 있었습니다. 특히 복잡한 로직을 구현할 때 TDD의 효과를 크게 체감했습니다.

마이크로서비스 환경에서 TDD/BDD 적용 시 가장 큰 어려움은 서비스 간 의존성 관리입니다. 각 서비스는 독립적으로 배포되지만, 결국 함께 동작해야 하므로 통합 테스트가 중요해집니다.

계약 기반 테스트(Contract Testing)를 활용하여 서비스 간 상호작용을 명확히 정의하고, 각 서비스가 계약을 준수하는지 확인합니다. 소비자 주도 계약(CDC)을 통해 계약 변경 시 영향을 받는 서비스를 빠르게 파악할 수 있습니다.

통합 테스트는 실제 서비스 대신 모의 객체(Mock)나 서비스 가상화를 사용하여 격리된 환경에서 진행합니다. 엔드투엔드 테스트는 최소화하고, 핵심 시나리오 위주로 수행하여 전체 시스템의 안정성을 검증합니다. 멱등성을 고려하여 테스트를 설계하는 것도 중요합니다.

TDD/BDD가 기능 요구사항에 집중하는 경향이 있는 건 사실입니다. 비기능 요구사항을 효과적으로 테스트하려면 몇 가지 전략이 필요합니다.

먼저, 인수 조건(Acceptance Criteria)을 확장해야 합니다. 단순히 기능 동작 여부뿐 아니라 성능 목표, 보안 제약 조건 등을 명시하는 거죠. 예를 들어 "로그인 기능은 1초 이내에 완료되어야 한다"처럼 구체적인 지표를 포함하는 겁니다.

다음으로, 비기능 테스트를 자동화합니다. 성능 테스트는 JMeter나 Gatling 같은 도구를 활용해 부하를 주고 응답 시간을 측정할 수 있습니다. 보안 테스트는 OWASP ZAP 같은 도구를 연동하여 취약점을 자동으로 검사할 수 있습니다.

마지막으로, 시나리오 기반 테스트를 활용합니다. 실제 사용 환경과 유사한 시나리오를 구성하여 스트레스 테스트나 내구성 테스트를 수행하는 거죠. 이를 통해 시스템의 안정성과 확장성을 검증할 수 있습니다. 계약 테스트를 통해 API 변경이 기존 시스템에 미치는 영향을 사전에 파악하는 것도 좋은 방법입니다.

TDD에서 Mocking/Stubbing은 격리된 단위 테스트를 위해 필수적이지만, 과도하면 오히려 독이 될 수 있습니다. 적절한 사용 시점은 협력 객체의 행동을 검증해야 할 때입니다. 즉, 특정 객체가 다른 객체에게 올바른 메시지를 전달했는지 확인하는 것이죠.

반면, 객체의 상태 변화를 검증하는 경우에는 실제 객체를 사용하는 것이 좋습니다. Stubbing은 단순히 값을 반환하는 용도로 사용하고, Mocking은 행동 검증에 집중해야 합니다.

Mocking Anti-patterns를 피하려면,

1. 테스트 대상을 명확히 하고, 그 대상의 협력 객체만 Mocking합니다.
2. Dependency Injection을 활용하여 Mocking을 쉽게 만듭니다.
3. 통합 테스트를 통해 단위 테스트의 한계를 보완합니다.

Private Method Mocking은 최대한 피하고, 리팩토링을 통해 테스트 가능한 구조로 변경하는 것을 고려해야 합니다.

TDD/BDD를 CI/CD에 통합하는 핵심은 빠른 피드백과 품질 게이트를 자동화하는 것입니다.

먼저, TDD는 개발 초기 단계부터 자동화된 단위/통합 테스트를 작성하게 하여 코드 품질을 높이고, BDD 시나리오는 비즈니스 요구사항을 명확히 하여 개발자와 테스터 간의 이해를 돕습니다. 이 테스트들은 CI/CD 파이프라인의 초기 단계에 통합되어 코드 변경 시마다 자동으로 실행됩니다.

테스트 자동화는 CI/CD의 핵심이며, TDD/BDD는 이를 위한 견고한 기반을 제공합니다. 개발자는 코드를 커밋하는 즉시 테스트 결과를 받아볼 수 있어 버그를 조기에 발견하고 수정할 수 있습니다.

배포 자동화는 이러한 자동화된 테스트를 통과한 코드만이 다음 단계로 진행하도록 하는 품질 게이트 역할을 합니다. 실패한 테스트는 배포를 차단하여 불안정한 코드가 프로덕션에 배포되는 것을 방지합니다.

피드백 루프는 TDD/BDD를 통해 더욱 강력해집니다. 개발자는 코드 작성과 동시에 테스트 결과를 확인하고, 실패 시 즉각적인 피드백을 받아 수정합니다. CI/CD 파이프라인은 이러한 테스트 결과를 종합하여 개발팀에 전달하며, 지속적인 개선을 유도합니다.

실패한 테스트는 배포 프로세스에 치명적인 영향을 미칩니다. 이를 관리하기 위해, 실패한 테스트가 발견되면 해당 빌드는 즉시 중단되고, 개발팀은 문제 해결에 집중해야 합니다. 심각한 경우, 이미 배포된 버전으로의 롤백(Rollback) 전략도 준비되어 있어야 합니다. 이는 자동화된 테스트가 프로덕션 환경의 안정성을 보장하는 게이트키퍼 역할을 수행하도록 하는 것입니다.

레거시 시스템에 TDD/BDD를 도입할 때 가장 큰 어려움은 테스트 격리가 어렵다는 점입니다. 코드 의존성이 높고, 테스트하기 어려운 전역 상태나 싱글톤 패턴이 많이 사용된 경우가 많습니다.

극복 전략으로는 먼저 'Seam'을 활용하여 의존성을 분리합니다. 핵심 로직을 감싸는 Seam을 만들고, 이 Seam을 통해 외부 의존성을 주입하여 테스트를 용이하게 만듭니다.

또한, 'Golden Master' 테스트를 활용하여 기존 시스템의 동작을 캡처하고, 변경 후에도 동일한 결과를 내는지 검증합니다. 점진적으로 코드를 리팩토링하면서 테스트 커버리지를 확보하고, 새로운 기능 개발 시에는 TDD/BDD를 적용하여 코드 품질을 높입니다. 중요한 것은 한 번에 모든 것을 바꾸려 하지 않고, 작고 안전한 변경을 반복하는 것입니다.

BDD를 조직 전체에 성공적으로 도입하려면 문화적, 기술적 토대가 중요합니다. 먼저, 비즈니스 용어와 개발 용어를 통합하는 '공통 언어'를 구축해야 합니다. Gherkin과 같은 도구를 활용하여 시나리오를 작성하고, 모든 이해관계자가 이해할 수 있도록 돕습니다.

기술적으로는 자동화 테스트 환경 구축이 필수적입니다. 테스트 코드를 'Living Documentation'으로 활용하여 요구사항 변경 시 즉각적인 피드백을 제공해야 합니다.

저항이나 오해를 해소하기 위해서는 점진적인 도입과 성공 사례 공유가 효과적입니다. 작은 프로젝트부터 시작하여 성공 경험을 만들고, 이를 조직 전체에 공유하면서 BDD의 가치를 알리는 것이 중요합니다. 또한, 애자일 코칭을 통해 협업 문화를 조성하고 지속적인 피드백을 장려해야 합니다.