TDD(Test Driven Develop) - Front End 관점 (1)

글이 너무 길어져서 쪼갭니다.

(1) TDD 이론
(2) Front End에서 TDD

 
요즘 개발자를 꿈꾸거나, 현업에서 개발을 하고 있는 사람들이라면 TDD를 안 들어본 사람은 거의 없을거라 생각한다. 나도 테스트를 먼저하고, 중심으로 개발한다. 정도의 개념으로는 알고 있었다. 
근데 면접에서 질문을 받았는데 사실 되게 쉬운 건데도 자세히 모르다보니 걍 모르겠다고 했다 ㅋㅋ... 꼬리질문 받으면 곤란할까봐 ㅎㅎ.. 
이상하게도 서류는 잘 붙는 사람... 
 
이 기회에 한 번 정확히 어떤 이론이며 어떻게 활용되고 있는지 또 어떤 기업에서 활용하고 있는지 알아보자!!
 
 

현업 개발자들도 누구나 실수를 한다. 그러나 본 서비스를 진행하는 과정에서 예상치 못한 오류를 마주하면 비용적, 시간적 측면에서 손해가 난다. 이러한 과정을 예방할 수 있는 것이 TDD이다.  

---

TDD란 무엇인가?

TDD (Test Driven Development)

말 그대로, '테스트 주도 개발' 이다. 
일종의 소프트웨어 방법론인데,, 반복 테스트를 이용해 작은 단위의 테스트 케이스를 작성하고 그를 통과하는 코드를 추가하는 단계를 반복해서 구현한다. 
 
짧은 개발 주기의 반복에 의존하는 개발 프로세스이며, 애자일 방법론 중 하나인 eXtream Programming(XP)의 'Test-First'에 기반을 둔 단순한 설계를 중요시 한다. 
 

eXtreme Programming(XP)

미래에 대한 예측을 하지 않고 지속적으로 프로토타입을 완성시키는 애자일 방법론 중 하나이다. 추가 요구 사항이 생기더라도 실시간 반영이 가능하다. 

Unit Test(단위 테스트)란?
한 단위(일반적으로 class)만을 테스트하는 것이다.

 

TDD 개발 주기

 

TDD 개발 주기

• RED 단계에서 실패하는 테스트 코드를 먼저 작성
• Green 단계에서 테스트 코드를 성공하기 위한 실제 코드를 작성
• Blue 단계에서 중복 코드 제거, 일반화 등의 리팩토링 수행

💡 실패하는 테스트 코드를 작성할 때까지 실제 코드를 작성하지 않는다. 실패하는 테스트를 통과할 정도의 최소 실제 코드를 작성해야 하는 것이다. 이를 통해 실제 코드에 대해 기대하는 바를 보다 명확하게 정의 함으로써 불필요한 설계를 피할 수 있고, 정확한 요구 사항에 집중할 수 있다.

 

일반 개발과 TDD 개발의 비교

일반 개발 방식

요구사항 분석 -> 설계 -> 개발 -> 테스트 -> 배포

일반 개발 방식인 요구사항 분석 -> 설계 -> 개발 -> 테스트 -> 배포는 잠재적 위험이 존재한다.
WHY?
1. 소비자의 요구사항이 처음부터 명확하지 않을 수 있음
2. 처음부터 완벽한 설계는 어려움
3. 자체 버그 검출 능력 저하 또는 소스 코드의 품질이 저하될 수 있따. 
4. 자체 테스트 비용 증가
 
=> 고객의 요구 사항 또는 디자인 오류 등으로 인해 재설계를 점진적으로 거친다. 
재설계로 인한 코드의 삽입, 수정, 삭제 과정에서 불필요한 코드가 남거나 중복 될 가능성이 크다. 
=> 버그 검출 능력의 저하로 이어진다. 
 

TDD 개발 방식

테스트 코드 작성 -> 실제 코드 작성을 한다.
디자인(설계) 단계에서 프로그래밍 목적을 반드시 미리 정의하고, 무엇보다 테스트해야 할 지 미리 정의(테스트 케이스 작성)해야 한다.
테스트 코드를 작성하는 도중 발생하는 예외 사항(버그 및 수정사항)은 테스트 케이스에 추가하고 설계를 개선한다. 

💡 JUnit?
현재 전 세계적으로 가장 널리 사용되는 'Java 단위 테스트 프레임워크'
CUnit(C++), CPPUnit(C++), PyUnit(Python) 등 다양한 xUnit 프레임워크가 있다. 


💡 xUnit?
자바 단위 테스팅 프레임 워크인 JUnit 만 있는게 아니다. 
다른 언어도 단위 테스트 프레임워크가 존재하며 이를 보통 xUnit이라 지칭한다. 

 

TDD 개발 방식의 장점

1) 보다 튼튼한 객체 지향적인 코드 생산

TDD는 "코드의 재사용 보장"을 명시한다. 기능 별 철저한 모듈화가 이루어진다. 이는 종속성과 의존성이 낮은 모듈로 조합된 소프트웨어 개발을 가능케하며, 필요에 따라 모듈을 추가하거나 제거해도 소프트웨어 전체 구조에 영향을 미치진 않는다. 

2) 재설계 시간의 단축

테스트 코드를 먼저 작성하기 때문에 개발자가 지금 무엇을 해야하는지 분명히 정의하고 개발을 시작하게 된다. 또한 테스트 시나리오를 작성하며 다양한 예외사항을 생각해 볼 수 있다. 이는 개발 진행 중 소프트웨어 전반적인 설계가 변경되는 일을 방지할 수 있다.

3) 디버깅 시간 단축

유닛 테스팅을 하는 이점이다. 데이터가 잘못 나온다면 DB 문제인지, 비즈니스 레이어의 문제인지 UI 문제인지 실제 모든 레이어를 전부 디버깅 해야하지만, TDD의 경우 자동화 된 유닛 테스팅을 전제하므로 특정 버그를 손 쉽게 찾아낼 수 있다.

4) 테스트 문서의 대체 가능

SI 프로젝트 진행 과정에선 어떤 요소들이 테스트 되었는지 테스트 정의서를 제작한다. 이것은 단순 통합 테스트문서에 지나지 않는다. 하지만 TDD를 하게 될 경우 테스팅을 자동화 시킴과 동시에 보다 정확한 테스트 근거를 산출할 수 있다.

5) 추가 구현의 용이함

개발이 완료된 소프트웨어에 어떤 기능을 추가할 때 가장 우려되는 점은 해당 기능이 기존 코드에 어떤 영향을 미칠지 알지 못한다는 것이다. TDD의 경우 자동화된 유닛 테스팅을 전제하므로 테스트 기간을 획기적으로 단축시킬 수 있다. 
 

TDD의 단점

생산성

개발 속도가 10~30% 정도 늘어난다. 왜냐하면 처음부터 2개의 코드를 짜야하고 중간중간 테스트를 하며 고쳐나가야 하기 때문이다.
=> SI 프로젝트에서는 소프트웨어 품질보다 납기일 준수가 훨씬 중요하기 때문에 TDD 방식을 잘 사용하진 않는다. 
 

TDD가 어려운 이유

1. 개발 방식을 바꿔야 한다. 
2. TDD는 이렇게 해야한다는 이미지(틀)이 있다. 

• 반드시 툴(단위 테스트 프레임워크)을 써서 개발해야 한다고 생각한다.
• 이런 규칙에 얽매이는 것은 애자일이 아니다! 
• 결국 규칙에 얽매여 같은 테스트를 COPY&PASTE
• 도구/규칙에 집착해 TDD가 어려워지는 것이다. 

 

TDD를 잘하는 법

계속해서 본인이 일하는 방식을 업그레이드 하자.
예를들어 게임 개발 시 stage3을 테스트 할 때 -> 1,2부터 클리어한 후 테스트해야한다.
=> 비용 증가 => stage3에서 바로 테스트 가능하도록 만든다. 
 
Back Door 접근 법 : 테스트 할 때 파라미터를 적용해 본인이 원하는 시스템의 시작점으로 가게 하는것 .

---

 
 
 
 
 

TDD란? 테스트 주도 개발 - 하나몬

실전에서 TDD하기 | 카카오페이 기술 블로그

 

Test-Driven Development Tutorial – How to Test Your JavaScript and ReactJS Applications

 

리액트TDD - Jest와 테스팅 라이브러리

[카카오 기술 블로그 - BackEnd]
 

테스트 코드 한 줄을 작성하기까지의 고난