어디까지 TDD를 해야 할까?

사이드 프로젝트 회의를 진행하면서 TDD(Test Driven Development) 대한 이야기가 나왔고 TDD에 대해 아직
정확하게 사용해보지 못해봤고 들어만 봤기 때문에 어디까지 테스트를 진행하고 어떤 부분에 테스트를 도입해야 되는지 감이 잡히지 않아 여러 사이트와 영상을 들으면서 제가 느낀 부분에 대해 정리를 해놓은 글입니다. 많은 피드백 바랍니다. 

TDD란

TDD를 위키에 정의된 내용은 아래와 같이 정의가 되었습니다.

테스트 주도 개발(Test-driven development TDD)은 매우 짧은 개발 사이클을 반복하는 소프트웨어 개발 프로세스 중 하나이다.
개발자는 먼저 요구사항을 검증하는 자동화된 테스트 케이스를 작성한다. 그런 후에, 그 테스트 케이스를 통과하기 위한 최소한의
코드를 생성한다. 마지막으로 작성한 코드를 표준에 맞도록 리팩토링한다

이것을 쉽게 풀어 내자면 각 기능에 대한 테스트 케이스를 먼저 생성하고 테스트하고 테스트가 실패하면 다시 돌아가서 리팩토링을 하고 테스트를 통과시킴으로써 코드를 간단하고 버그가 없는 코드로 만들기 위한 개발 프로세스 입니다.

TDD 진행 방식

• 테스트를 추가합니다.
• 기존에 있는 모든 테스트를 실행하고 실패하는 새로운 테스트 코드를 작성합니다. 
• 실패하는 테스트를 성공시킬 코드를 작성합니다.
• 테스트를 실행하고 실패한다면 코드를 리팩토링 합니다.
• 이과정을 반복합니다.

TDD의 장점

조기 버그를 찾을 수 있다.

• 우리는 코드를 테스트 하지만 보통 데이터 베이스에서 수동으로 확인하거나 일회용 API 조회를 통해 테스트를 하게 됩니다.
• 하지만 TDD를 하면서 조기에 버그를 찾으면서 좀 더 견고한 비지니스 로직을 구성할 수 있고 추후에는 테스트 자동화를 통해 비지니스 로직의 무결성을 검증할 수 있습니다.

더 나은 디자인과 확장 가능한 클린 코드 작성

• 코드가 사용되는 방식이나 다른 모듈과의 상호 작용을 이해하는데 도움이 됩니다.
• 결과적으로 더 나은 디자인의 유지 보수하기 쉬운 코드를 작성할 수 있습니다.
• TDD를 사용하게 되면 여러 책임이 있는 모놀리식 절차보다 객체 지향적으로 단일 책임을 가진 더 작은 코드를 작성할 수 있습니다.
• TDD는 사용자 요구 사항에 따라 테스트를 통과하기 위한 프로덕션 코드만 작성하도록 합니다.

리팩토링에 대한 자신감

• 코드를 중간에 리팩토링을 하다보면 중간에 있는 비지니스 로직이 중단 될 가능성이 있습니다. 하지만 자동화된 테스트를 통해 이러한 중단을 개선하고 적절할 예외 처리를 할 수 있습니다.
• 이처럼 최소한의 에러로 업데이트할 수 있는 버그가 적어지고 더 퍼포먼스가 좋고 확장 가능한 비지니스 로직을 작성할 수 있습니다.

팀워크

• 같이 프로젝트를 진행 하지 않은 다른 팀원이 쉽게 코드를 분석하고 작업할 수 있으며 또한 공유한데 있어서 효율적으로 공유할 수 있습니다.

개발자로서의 이점

• 개발자는 TDD 케이스를 작성하는데 있어서 더 많은 시간을 투자해야 되지만 새로운 기능을 개발하는데 있어서 디버깅에 소요하는 시간이 줄어들고 더 깨끗하고 덜 복잡한 코드를 작성할 수 있습니다.

느낀 점

이처럼 TDD의 장점을 인지하고 있지만 어디서 부터 어떻게 실무에 적용해야 될지 주니어 개발자로써 방향이 잘 잡히지
않았습니다. 그렇게 여러 영상과 자료들을 찾아 보다가 OKKY에 대해 글을 읽어 보고 그와 관련된 세미나 영상까지 보고나서야 희미하게 방향성이 잡혔었습니다.

 

그와 관련해서 주니어가 연습하는 방법에 대해 5단계로 정리를 해주셨는데 아래와 같습니다.

 

1단계 - xUnit 사용법과 단위 테스트 연습

- 유틸성 메소드에서 시작.
- JDK와 같이 누군가 제공하는 API 사용법을 익히기 위한 학습 테스트
- 알고리즘 연습할 때 적용해도 좋음

2단계 - TDD 연습

- 요구 사항이 명확한 프로그램
- 의존 관계(모바일 UI, 웹 UI, 데이터 베이스)가 없는 예제로 연습
- 로또, 사다리타기, 볼링 점수판과 같은 토이 프로젝트도 좋음

3단계 - 리팩토링과 객체지향 설계

- 같은 요구사항을 반복해서 연습
- 연습할 때 마다 제약 사항을 한개씩 추가하면서 난이도를 높힙니다.
- 객체 지향 설계 1단계 제약 사항
▶ 한메소드에 오직 한단계의 들여쓰기를 한다. (ex: 하나의 메서드안에 for문안에 if문을 사용하면 확장성 ↓)
▶ else를 최대한 지양한다.
▶ 모든 기본형 타입은 감싼다.(int, long, string과 같은 변수를 객체로 감싼다.)
▶ 일급 컬렉션을 사용한다. (콜렉션을 포함한 클래스는 반드시 다른 멤버 변수가 없어야 한다.)
- 리팩토링 제약 사항
▶ 리팩토링 과정에서 컴파일 에러가 일어나면 안됩니다.

4단계 - 웹/모바일 프로젝트에 적용

- 앞에 3단계와 병행합니다.
- 처음부터 바로 현장에 적용하는 것은 안됩니다.
- 래거시 환경에 적용한다는 것은 매우 난이도가 높은 스킬입니다.

5단계 - ATDD와 CI적용

- ATDD (End to End 테스트)를 적용
- CI를 통해 지속적 피드백이 가능한 환경 구축

연습하기전 가져봐야 할 것

• 조급하지말고 여유를 가지고 해야합니다.
• 같은 과제를 계속 반복적으로 구현하는데 있어서 끝까지 할 수 있는 인내력(TDD는 지루합니다.)
• 나만의 토이프로젝트가 있어야 합니다.
• 자신의 길을 계속 개척하고 꾸준히 도전할 수 있는 용기

 

정리

그리고 다른 좋은 글도 많이 있지만 제가 대략적으로 정리를 하자면 일단은 간단한 기능을 하는 로직부터

테스트(테스트 하기 쉬운 코드)를 하면서  계속 제약사항을 추가하면서 테스트 하기 어려운 코드를 쉬운 코드로

개발할 수 있을 때 까지 해봐야 할 것 같습니다.

 

역시 지름길은 없네요.. TDD를 배우시는 분도 꾸준히 하시면서 점진적으로 발전하시길~

 

출처

https://okky.kr/article/476113

OKKY | TDD 잘알못을 위한 돌직구 세미나 참석 후기

https://www.guru99.com/test-driven-development.html#2