세션2. TDD 소개
1. 인터페이스 설계와 구현 설계
시스템
특정한 목적을 달성하기 위해 여러 구성 요소가 함께 상호작용하며 작동하는 단위
시스템은 시스템을 외부와 구별하는 경계를 가지고 인터페이스를 통해 외부와 소통
하나의 시스템은 여러 하위 시스템으로 구성될 수 있다.
응용프로그램, 모듈, 클래스, 함수, ...
클라이언트
시스템이 제공하는 기능을 사용하는 주체
인터페이스를 통해서 시스템에 접근
시스템을 이용하며 대가를 지불하는 고객같은 사용자가 있다.
외부 응용프로그램이나 한 클래스를 사용하는 다른 클래스가 있다.
인터페이스 설계
인터페이스는 클라이언트와 상호작용하기 위한 소통 약속이다.
인터페이스 설계는 클라이언트의 요구사항 반영한다.
인터페이스 설계 변경은 클라이언트에 영향을 준다.
만약 클라이언트가 이런 영향을 거부한다면 인터페이스 설계 변경은 불가능하다..
구현 설계
구현 설계는 인터페이스를 통해 제공되는 기능 요구 사항을 충족시킨다.
구현 설계는 비기능 요구사항(성능, 보안, 개발 생산성...)도 충족시키며 제작공정의 품질에 영향을 준다.
변경 여파가 미치는 범위가 시스템 내부로 한정된다.
때문에, 대안의 폭이 넓고 변경이 잦다..
리팩터링
제작공정 품질을 높이기 위해 기능과 인터페이스 설계를 유지하며 구현 설계를 변경할 수 있다.
이런 활동을 리팩터링(refectoring)이라고 부른다.
클라이언트가 사용하는 인터페이스의 설계 변경을 포함하는 활동은 리팩터링이 아니며, 리디자인(redesign) 이라 표현하기도 한다.
기능과 인터페이스 설계가 유지되기 때문에, 리팩터링은 클라이언트에 아무런 영향을 주지 않는다.
리디자인은 클라이언트에게 영향이 가기 때문에, 많은 자원을 계획적으로 할당해야 하는 반면,
다른 동료에게 리디자인에 대한 일정 공유는 필수적이다! (영향이 많다!)
리팩토링은 클라이언트에게 영향이 가지 않기 때문에, 특별한 자원 할당 없이 일상적인 개발 과정의 일부로 수행된다.
다른 동료에게 리팩토링에 대한 일정 공유는 필요 없다.. (영향이 없으니,,)
2. 테스트와 설계
테스트 시나리오
제품이 갖춰야 할 기능을 검증하는 작은 단위
다양한 제품 요구사항 표현 방법 중 하나이다.
대부분 클라이언트 관점에서 작성된다.
제품의 가치와 품질을 결정하는 주요 요소이다.
모든 프로그래머는 의식적으로 또는 무의식적으로, 문서화하든 또는 머릿속에서만 정리하든, 명확하게 또는 희미하게 테스트 시나리오를 구성한다.
해당 강의에서 '테스트 시나리오'는 명확하게 문서화한 테스트 시나리오를 의미한다.
자동화된 테스트
테스트 시나리오의 구체적인 내용이 동작하는 코드의 문법으로 작성된 문서이다.
Junit 과 같은 테스트 프레임워크
저렴하게 테스트 시나리오를 검증한다.
반복 실행하기 쉽다.
검증 결과의 신뢰도가 높다.
설계 관점의 테스트
"단위 테스트 운영 API 의 첫 번째 클라이언트입니다" - Mark Seemann
기능을 사용하기 위해서 시스템의 인터페이스를 개발 후 가장 먼저 호출할 수 있다.
클라이언트는 공개된 인터페이스 설계에만 의존하는 것이 원칙이다.
내부의 구현 설계와는 직접적인 관련이 없다.
클라이언트가 시스템 내부에 감춰진 구현 설계에 의존하게 되면 시스템은 다양한 위험에 노출된다.
구현 설계에 의존하지 않는 원칙은 클라이언트의 일종인 테스트에도 동일하게 적용된다.
구현 설계에 의존하는 테스트와 구현 설계 변경의 여파
대부분 구현 설계의 여파는 시스템 내부로 한정되고 그 여파는 크지 않다.
클라이언트에게 전파되지 않는다.
하지만, 구현 설계의 변경이 외부로 전파된다면 모든 클라이언트(테스트) 가 해당 변경에 대응해야 한다.
만약 해당 구현 설계와 수많은 테스트가 연관되어 있다면 모든 테스트가 변경에 대응해야 한다.
3. TDD(Test-Driven Development) 절차
Kent Beck 이 정의한 TDD 절차 (생각보다 간단하다)
다루고자 하는 테스트 시나리오의 목록을 작성한다.
목록에서 정확히 한 가지 항목을 실제 실행 가능한 구체적인 테스트로 전환한다.
전환된 테스트(및 모든 이전 테스트) 를 통과하도록 코드를 변경한다.
테스트 시나리오가 발견되는 대로 항목 추가
선택적으로 리팩터링하여 구현 설계를 개선한다.(리팩터링)
목록이 비워졌는지 확인한다.
비워졌다면 종료한다.
아니라면 2. 로 돌아간다.
1. 다루고자 하는 테스트 시나리오의 목록을 작성한다.
대상 기능에 대한 떠올릴 수 있는 모든 테스트 시나리오를 나열한다.
성공, 실패 모두 포함
Kent Beck 은 테스트 시나리오 목록 작성을 본인의 책에서 설명하였지만 많은 사람들이 그걸 놓친 것 같다 말했다.
테스트 시나리오 목록은 TDD 과정 뿐 아니라 제품의 품질에 큰 영향을 미친다. (그만큼 중요하다!)
2. 목록에서 정확히 한 가지 항목을 실제 실행 가능한 구체적인 테스트로 전환한다.
테스트 시나리오 목록에서 정확히 하나를 선택해서 이 시나리오에 해당하는 자동화된 테스트를 작성한다.
테스트에 의해 인터페이스가 처음으로 사용된다.
핵심: 이 시점에는 테스트에 사용되는 클래스가 아직 존재하지 않거나, 존재하더라도 메서드가 아직 구현되지 않았거나, 잘못 구현되어 있어야 한다.
테스트 작성이 완료되면 실행해서 실패 결과를 확인한다.
운영 코드를 변경하지 않은 이유로 인해 실패해야 한다.
방금 작성한 테스트를 실행하면 반드시 실패해야 한다. 왜냐하면 메서드를 아직 구현하지 않았거나, 잘못 구현했기 때문이다.
만약 테스트가 성공한다면? 뭔가 잘못된 것이다. (
해당 케이스는 이후 내용에서 다룬다..)
이 단계에서 테스트가 실패하는 것이 정상이다. 만약 성공했다면, 그것은 테스트 코드 자체를 다시 검토해야 한다는 신호이다.
인터페이스 설계 시점
독립적인 작업(외부 의존성X)이라면 "2. 목록에서 정확히 한 가지 항목을 실제 실행 가능한 구체적인 테스트로 전환한다." 단계에서 시작할 수 있다.
협업에 필요한 인터페이스라면 "1. 다루고자 하는 테스트 시나리오의 목록을 작성한다." 단계에서 초안이 작성될 수 있다.
예를 들어, 여러 개발자가 함께 작업해야 하는 기능, 특히 프론트엔드-백엔드 간, 또는 다른 모듈 간의 연동이 필요한 경우를 말한다. 이 경우에는 기능 구현 이전에 '어떤 시나리오로 테스트할 것인지'에 대한 목록을 먼저 작성하여 인터페이스의 초안을 함께 정의하는 것이 중요하다. 이는 일종의 "계약서"를 미리 작성하는 것과 같다.
독립적인 작업인 경우에도 1번 단계에서 테스트 시나리오 목록과 인터페이스 설계 초안을 함께 작성하면 두 작업이 서로 긍정적인 영향을 끼친다.
"사용자 정보 유효성 검증"과 같은 독립적인 기능도, 바로 테스트를 작성하기보다는 어떤 케이스를 테스트할지 목록을 먼저 만들고 그 과정에서 인터페이스를 구체화하면 더 좋다.
3. 전환된 테스트(및 모든 이전 테스트) 를 통과하도록 코드를 변경한다.
모든 테스트를 통과하도록 운영 코드를 변경한다.
테스틑 통과하게 만드는 데 집중한다.
코드가 깨끗한지 또는 중복되는지는 중요하지 않다.
모든 테스트가 통과하는 것을 확인 후. 새로 추가한 테스트에 해당하는 시나리오에 완료 표시한다.
이 단계에서 "1. 다루고자 하는 테스트 시나리오의 목록을 작성한다." 단계에서 떠올리지 못한 새로운 테스트 시나리오가 발견되면 목록에 추가한다.
4. 선택적으로 리팩터링하여 구현 설계를 개선한다.(리팩터링)
구현 설계를 개선할 필요가 있다면 판단되면 리팩터링한다.
이 단계는 선택적이다.
하지만, 리팩터링을 해야할지 판단하는 과정을 쉽지 않다..
리팩터링이 완료되면 모든 테스트를 통과하는지 다시 확인한다.
5. 목록이 비워졌는가?
비워졌다면 종료한다.
아니라면 2. 로 돌아간다.
4. 지금 시점의 TDD 의 의미
TDD 는 우리를
의식적으로 구체적인 테스트 시나리오 목록을 기록하게 한다. (구조적인 이점)
두려워하지 않고 앞으로 나아갈 수 있게 한다. (감정적인 이점)
구현 코드의 설계보다 제품의 가치에 집중하게 한다. (효율적인 이점)
생성형 AI 보급이 프로그래머에 미치는 영향
제품 개발의 궁극적인 목적은 사람에게 가치를 전달하는 것이다.
제품 개발자는 가치 전달 과정에서 발생할 수 있는 기대하지 않은 피해를 차단해야 한다.
주어진 요구사항에 대한 구현 코드나 그 초안을 만드는 생성형 AI 의 능력은 빠르게 향상되고 있다.
프로그래머는 구현 코드의 설계보다 올바른 가치 전달을 위해 필요한 논리적이고 모순되지 않으며 구체적인 요구사항 제시에 더욱 기여해야 한다.
생성형 AI 보급과 TDD
TDD 는 올바른 요구사항 제시를 유도 또는 장려한다.
유사한 흐름을 공유하는 테스트를 반복해서 작성할 때 생성형 AI 는 뛰어난 도구이다.
테스트로 표현된 요구사항은 생성형 AI 에게 구현 코드 작성을 주문하는 효과적인 입력이다.
생성형 AI 는 테스트 작성과 구현 코드 작성에서 모두 TDD 비용을 줄여 준다.
AI 코드 생성 능력은 프로그래머가 구현 코드가 아닌 소프트웨어 가치에 집중할 수 있게 한다.
소프트웨어의 본질적인 존재 목적이 아닐까?
TDD 를 통해 확보된 소프트웨어 가치에 기반한 테스트 집합은 시스템에 지속적으로 추가되는 AI 생성 코드가 가질 수 있는 오류와 위험을 효과적으로 방어할 수 있다.
결론적으로, TDD 는 더 필요해질 수 밖에 없다.
AI 를 통한 생산성 향상으로 인한 코드에 대한 안전망 필요 = 테스트코드
그 테스트 코드마저 AI 에게 요청 가능 = 비용 절감
5. 거짓 양성과 거짓 음성
거짓 양성(false positive)
주어진 조건이 존재하지 않을 때 존재한다고 나타내는 결과이다.
예를 들어, 여성이 임신하지 않았는데, 임신했다고 나타내는 임신 테스트나 무고한 사람의 유죄 판결이 있다.
거짓 음성(false nogative)
조건이 유지되지 않음을 잘못 나타내는 테스트 결과이다.
예를 들어, 임신 검사에서 여성이 임신하지 않았다고 표시되지만 실제로는 임신한 경우, 또는 범죄를 저지른 사람이 무죄 판결을 받는 경우가 있다.
소프트웨어 테스트에서의 거짓 양성과 거짓 음성
거짓 양성은 성가신 문제이다. 테스트의 오류를 수정하거나 테스트 환경을 안정화하면 해결할 수 있다. 간헐적으로 발생하는 경우 우리를 더 귀찮게 한다.
거짓 음성은 위험하다. 운영 코드에 문제가 있음에도 불구하고 아무런 신호도 주지 않아, 적절한 조취를 취할 수 없기 때문이다. 결국 클라이언트가 피해를 입게 된다.
6. TDD 에 대한 오해
Mock 을 잘 사용해야 TDD 를 잘 할 수 있다.
"저는 테스트 대역을 거의 사용하지 않습니다." - Kent Beck
Java 의 경우 Mockito 를 잘 사용해야 한다는 주장이 있다.
테스트 환경에서 실제 구성 요소를 대체하는 시스템을 지칭할 때, '테스트 대역(test double)' 이라는 표현이 명확하다.
xUnit 테스트 패턴에서 Mock 은 테스트 대역의 여러 가지 유형 중 하나이다.
http://xunitpatterns.com/Mocks, Fakes, Stubs and Dummies.html
테스트 대역이 유용한 경우가 분명이 있지만, 남용하면 운영 코드와 테스트 간의 정보 공유가 비대해져 설계 변경 비용이 증가하고, 테스트 환경의 가정을 확대해 거짓 음성이 발생할 가능성이 높아진다.
테스트 대역을 사용하더라도 반드시 별도의 도구가 필요한 것은 아니다.
본 강의의 실습은 테스트 대역을 사용하지 않는다.
테스트를 위해 프로젝트 구조를 설계해야 TDD 를 잘 할 수 있다.
Java 의 경우 패키지 구조를 잘 설계하는 것은 다양한 이점이 있을 수 있으나 테스트에 미치는 영향은 미비하다.
오히려 외부에 드러난 인터페이스 설계와 내부에 감춰진 구현 설계의 명확한 구분이 테스트 작성에 많은 영향을 준다.
시스템의 적응력을 높이기 위한 아키텍팅의 결과로 모듈이 분리되었다면 자연스럽게 테스트 작성 비용이 낮아지겠지만, 설계 숙련도가 충분하지 않은 채 테스트 용이성만을 목적으로 모듈을 분리하면 오히려 거짓 음성을 야기할 수 있다.
인터페이스 형식을 많이 사용해야 TDD 를 잘할 수 있다.
Java 언어의 인터페이스 형식은 운영 코드의 변경과 확장 용이성을 확보하기 위해서 사용할 수 있다.
테스트 작성만을 고려해 인터페이스 형식을 도입한다면 테스트 대상 시스템, SUT(system under test) 가 의존하는 구성요소, 실제 DOC(depended-on component) 를 추상화해 테스트 환경에서 테스트 대역 사용을 사용하는 것이 유일한 목적이다.
이런 경우 실제 DOC의 행위가 변경되었을 때 테스트 환경에서 테스트와 SUT 는 실제 DOC 가 아닌 테스트 대역에만 의존하기 때문에, 거짓 음성이 발생할 수 있다.
만약 테스트 환경에서 실제 DOC 를 구동하거나 제어할 수 없는 상황이라면 거짓 음성의 위험과 SUT 코드를 테스트하는 효과의 거래도 고려할 만 하다.
하지만 그렇지 않다면, 테스트 작성만을 위한 인터페이스 형식 도입은 시스템의 설계 복잡도를 높이고 테스트 결과의 신뢰도를 떨어뜨리는 실수이다.
클래스를 작게 나눠야 TDD 를 잘할 수 있다.
구현 설계가 테스트에 노출된 경우가 아니라면 내부에 감춰진 구현 코드를 이루는 클래스나 함수의 크기는 테스트 작성과 TDD 에 영향을 주지 않는다.
클라이언트는 오직 인터페이스와 소통한다.
클린 아키텍처 또는 헥사고날 아키텍처를 사용해야 TDD 를 잘할 수 있다.
적응력 높은 설계를 확보하면 그 효과중 하나로 테스트 작성 비용이 감소할 수는 있다. 그러나 팀과 코드 기반이 특정 아키텍처 도입에 충분히 준비되어 있지 않다면, 테스트 작성만을 목적으로 해당 아키텍처 도입 비용을 지불하는 것은 좋지 않은 결정일 가능성이 높다.
본 강의 실습의 시스템은 매우 단순한 아키텍처로 만들어지지만 모든 코드는 큰 불편함 없이 TDD 로 작성된다.
단위 테스트와 통합 테스트를 잘 분리해야 한다.
단위 테스트가 다루는 운영 코드 범위에 대한 명확한 합의는 아직 없다.
때문에, 단위 테스트와 통합 테스트를 구분하는 것은 쉽지 않을 뿐더러 더 중요하게는 강사 본인은 둘의 구분이 주는 긍정적인 효과를 거의 느끼지 못한다.
단위 테스트와 통합 테스트의 구분보다 요구사항 검증이 자동화되었는지 여부가 더욱 중요하다!
오히려 단위 테스트와 통합 테스트를 분명하게 나누려는 시도는 단위 테스트가 다루는 운영 코드 범위를 극도로 제한하려는 심리를 만들며, 이는 다음과 같은 현상을 유도해 거짓 음성 가능성과 설계 비용을 높인다.
과도하게 테스트 대역을 사용한다.
클라이언트에 제공되는 기능 수준의 설계보다 작은 단위의 하위 시스템 설계에 집중한다..
본 강의는 단위 테스트, 통합 테스트라는 용어를 거의 사용하지 않는다.
테스트 실행 시 데이터베이스 엔진 사용을 피해야 한다.
데스트 환경 전용 데이터베이스가 있다면 충분히 활용할 수 있다.
데이터베이스 엔진 사용이 너무 느려서 테스트를 실행하는 프로그래머가 답답함을 느끼거나 연결이 안정적이지 않다면 테스트 대역을 고려할 수 있고, 첫 번째 후보는 인메모리 데이터베이스 엔진이다.
본 강의 실습의 모든 테스트는 H2 인메모리 데이터베이스 엔진을 사용하며 불편하지 않을 정도의 속도를 보여준다.
데이터베이스 엔진 사용 시 롤백과 관련된 고민을 하고 있다면 본 강의 실습에서 소개하는 임의 테스트 데이터 생성을 통해 애초에 롤백이 필요없도록 할 수 있다.
Spring 컨테이너를 사용하는 테스트는 몹시 불편할 정도로 느리다.
불편함과 느림은 상대적인 척도이기 때문에, 명백하게 틀린 주장이라고 할 수는 없다.
동일한 기능을 다룰 때 Spring 컨테이너를 사용하지 않는 테스트가 대부분 더 빠른 것은 사실이다.
수십 회 HTTP 요청을 사용하는 복잡한 테스트 여럿을 포함한 본 강의 실습의 120여 개 테스트는 모두 Spring 컨테이너를 사용하며 전체 실행 시간은 약 25초이다. 강의 후반의 ‘테스트 성능 개선’ 수업에서는 실행 시간을 크게 줄여서 약 6초로 감소된다.
*강의 영상에서는 화면 녹화 중인 이유로 더 긴 시간이 소요됩니다.
본 강의 실습은 Spring Boot 응용프로그램 개발에 TDD를 사용하는 가장 쉽고 기본적인 기법만을 소개한다. 실무에서 다양한 기법을 활용하는 경우 비슷한 수의 테스트 실행 속도는 몇 배 더 빨라질 수 있다.
Last updated
