TIL 230717 : TDD? BDD?

이전 시간 테스트 코드를 작성하다 given메소드를 가져오면서 본 임포트 문이다.

BDD?

 

TDD, BDD라는 용어가 있고 더불어 튜터님덕에 DDD까지 알게 되었다.

 

우선 TDD부터 알아보자.

 

TDD

 

우선 Test Driven Development이 TDD의 약자이다.

테스트가 개발을 주도하는 의미이다.

특정한 개발기능이라기 보단 개발을 하는 방향성? 습관? 의 느낌이다.

 

TDD 사이클 

- 테스트 케이스를 하나 추가한다. 

- 모든 테스트를 실행하고 새로 추가한 것이 실패하는지 확인한다. 

- 테스트를 통과하기 위한 코드를 작성한다. 

- 모든 테스트를 실행하고 전부 성공하는지 확인한다. 

- 리팩토링을 통해 중복을 제거한다.

 

위는 TDD사이클인데, 이를 반복하며 자연스럽게 테스트를 위한 코드를 만들고 작은 기능에서부터 검증이 시작된다.

이렇게 출발한 개발은 다양한 장점이 있다.

 

TDD의 장점

• 각 모듈의 역할이 단순해지고 명확해짐
• 프로젝트의 유지보수와 확장이 쉬움
• 수동 테스트에서 시간을 단축할 수 있음
• 놓칠 수 있는 것들을 반복 테스트하기 좋음
• 프로젝트의 품질을 높이고, 효율적인 테스트 경험과 사용자의 입장을 고려한 개발을 진행할 수 있도록 해줌
• 실제 사용자의 실행 환경과 거의 동일한 환경에서  테스트를 진행하기 때문에, 실제 상황에서 발생할 수 있는 에러를 사전에 발견할 수 있음

 

솔직히 아직 와닿지가 않는다.

https://product.kyobobook.co.kr/detail/S000001032985

테스트 주도 개발 | 켄트 벡 - 교보문고

 

우연히 테스트주도 개발의 책추천을 하나 받았는데 참고해서 이후 연습을 좀 이어가봐야겠다.

 

 

BDD

 

Behavior Driven Development의 약자다. 행동이 개발을 만든다. 유저의 행동을 고려해가며 테스트를 주도하며 개발을 하는 개념으로서, 어찌보면 TDD와 겹치는 부분도 있으면서 개발 이전의 설계 단계에서의 설계 방향이다.

 

(좌) TDD, (우) BDD

 

각각의 차이가 있으면서도 공통분모가 있다.

이를 적절히 차용해가며 설계하는 것이 장점이라고 한다.

 

 

 

 

---

좀 더 공부해야할 점

 

1. 실제 TDD, BDD 방식의 작업프로세스.

 : 구글링으로 보게되는 작은 예시만으로는 와닿지 않는 부분들이 많다. 이에 대하여 이런 개념의 중요성과 실제 현업에서의 적용방식, 실제 예시등을 알게 되면 더욱 좋을 것 같다.

 

2. DDD

 

Domain Driven Design의 약자인 DDD.

아래 링크에서 간략하게 전체적인 느낌을 살펴보았는데, 자세한 공부는 이후에 이어나가보려 한다.

 

 

 

https://happycloud-lee.tistory.com/261?category=832246 

일하는 방식 변화 핵심만 빠르게 이해하기: 애자일, 마이크로서비스, 데브옵스, 클라우드

 

https://happycloud-lee.tistory.com/94

DDD 핵심만 빠르게 이해하기

 

 

---

 

생전 처음듣는 단어인데, 그 단어들이 현업에서는 너무나 유명한 말일때 기분이 좋다.

이젠 유튜브에서 쉽게 다루는 내용을 넘어선건가 하는 마음에서이다.

예전 영상을 시작할때는 유튜브에 의존해서 배웟는데 일정 수준 이상으로 넘어가면 유튜브에선 배울 정보들이 많이 사라진다. 그때의 경험과 비슷하게 생각이 되어서 지금 어느정도 기본적인 내용 이상의 것들도 조금씩은 경험하는 느낌이라 기분이 좋기도하다. 물론 기본을 다시 다질 필요도 동시에 조금씩 느끼면서.