TDD START!

저는 책을 읽다보니 TDD에 관심을 가지게 되었습니다.

해당 책에서는 실험을 통해 TDD에 대한 얘기를 했고 TDD 미적용시 30분 정도 걸리는 코드를 TDD를 적용시켰을 때 대략 10%정도 빠르게 작업이 완료되었다고 한다.

 

그래서 저도 TDD를 적용시켜보고자 자료를 찾아보던 중 DDD START!의 저자이신 최범균님의 TDD 유튜브를 찾게 되었습니다. (밑에 해당 유튜브의 링크를 걸어놨습니다.)

 

 

이제부터 작성하는 글은 해당 유튜브의 내용을 요약이니 유튜브를 직접 보시는 것을 강력히 추천드립니다.

최범균님께서 예시를 들어 실제로 TDD를 적용했을 때 어떻게 개발이 진행되는지를 라이브 코딩으로 보여주십니다. 😀

 

테스트 코드의 필요성

수동 테스트

- 검증 범위 누락 발생하기 쉽다.

- 예외 상항 검증하기 어렵다. (비정상 입력의 다양한 경우를 수동으로 테스트하기 힘들다.)

 

자동화된 테스트

- 실행할 수 있는 테스트이다.

- 테스트가 쌓일수록 수정한 코드로 인해 다른 코드에 문제가 생기지 않는지 확인 가능하다.

 

 

테스트 종류

UI(e2e) 테스트 : 내가 만든 시스템이 제대로 돌아간다는 확신이 높아진다.

서비스 통합 : 여러 작업 단위가 연계된 워크플로우를 테스트한다.

단위 테스트 : 작은 클래스 혹은 함수 메소드 단위로 테스트를 한다.

 

정리

- 테스트 코드로 검증해주기 때문에 추가 코드 작성에 있어 부담이 덜하다. 

- 문제는 주로 테스트 코드가 없는 지점에서 발생

- 당장 테스트 코드를 작성해 개발 시간이 늘어난다고 볼 수 있지만, 수동 검증하는 시간을 고려했을 때 오히려 시간을 단축시키는 결과를 가져온다.

 

TDD는 무엇인가?

TDD(Test Driven Development)는 테스트로부터 시작하는 개발 방식이다.

1. (실패하는) 테스트 코드 작성한다.

2. 테스트를 통과시킬 만큼 구현한다. 

3. 코드 리팩토링한다.

이 과정을 내가 만들고자 하는 코드가 만들어질 때까지 한다.

TDD로 구현의 장점

- 테스트가 개발을 주도한다.

- 개발 과정에서 리팩토링이 진행된며 사전에 코드가 더러워지는 것을 막는다.

- 빠르게 피드백하여 수정한 코드가 다른 기능에 영향을 주지 않는지, 내가 만든 코드가 올바른지 바로 알 수 있다.

- 테스트를 통과할 만큼만 코드를 작성하여 기능을 구현하는데 필요한 만큼만 구현하게 된다.

- TDD를 진행하면서 설계도 진행되며 테스트할 대상 이름, 기능 이름, 결과 타입 등의 설계를 진행하게 된다.

 

 

TDD를 적용할 때 테스트 코드는 어느 것부터 작성 순서는?

- (쉬운것 또는 예외적인 것) 부터 시작하여 점전적으로 (어려운 것, 정상인 것) 순으로 테스트 코드를 작성하는 것을 권장한다.

- 어려운 테스트를 먼저하게 되면 코드가 커지게 될 것이고, 어디서 오류가 났는지를 확인하기 보다 힘들어 질 것이다.

- 정상적인 테스트를 먼저 진행하게 된다면 정상상태에 대한 코드가 먼저 나오며 거기에 예외 상황이 들어가 유사한 if-else문이 들어갈 가능성이 존재한다.

 

 

 

 

 

 

 

 

 

참조

https://www.youtube.com/watch?v=L_1UYlJyNuk&list=PLwouWTPuIjUgZusVm_WuBVZXINH2BjP_O&index=10 

https://www.youtube.com/watch?v=6Vt-wKPBbuc&list=PLwouWTPuIjUgZusVm_WuBVZXINH2BjP_O&index=11 

https://www.youtube.com/watch?v=rs_ReNmLISw&list=PLwouWTPuIjUgZusVm_WuBVZXINH2BjP_O&index=12