📝 TDD 강의 정리

이번 로또 미션을 구현하면서 페어와 TDD를 연습하면서 강의에서 들었던 모든 이점들을 느낄 수 있었다.

사실 완벽하게 TDD를 진행했다고 자신할 수 없으나,
강의 내용에서 들었던 이점들을 페어와 함께 TDD를 진행하면서 경험할 수 있었다.

여기서는 TDD 강의 내용을 들으면서 정리한 것을 조금 가공해서 정말 간단히 기록한다 ✍️

TDD, 리팩토링이란?

TDD(Test Driven Development) - 테스트 주도 개발

프로덕션 코드

프로그램 구현을 담당하는 코드

테스트 코드

프로덕션 코드가 정상적으로 동작하는지 확인하는 코드

TDD란?

일반적으로는 프로덕션 먼저 구현 후 테스트 였는데 이건 테스트를 먼저 한 후 프로덕션을 개발한다.

TestFirstDevelopment + 리팩토링

테스트 코드를 만들고 프로덕션 후 리팩토링
리팩토링은 기능은 추가하지 않지만 설계를 변경하면서 유지보수 용이, 가독성을 챙긴다.

설계를 한번에 몰아서 하는게 아니라 작은 단위로 자주하자.
리팩토링은 설계일 수도 있고 다양한데 그 과정을 자주하자는 것.

TDD는 분석 기술이며, 설계 기술이기도 하다. - 켄트벡, Test Driven Development by Example 중

todo-list를 잘 작성하는게 요구사항 분석이다.
디버깅 시간이 줄어든다.

TDD 사이클

• 실패 테스트 구현
• 테스트 성공하도록 프로덕션 구현
• 프로덕션 코드와 테스트 코드 리팩토링

TDD 원칙

• 원칙 1 - 실패하는 단위 테스트를 작성할 때까지 프로덕션 코드를 작성하지 않는다.
• 원칙 2 - 컴파일은 실패하지 않으면서 실행이 실패하는 정도로만 단위 테스트를 작성한다.
• 원칙 3 - 현재 실패하는 테스트를 통과할 정도로만 실제 코드를 작성한다.

무조건 실패 테스트를 본 후 프로적션 코드를 작성한다.

TDD 이점

마음의 편안

요구사항 수정에 소스 코드를 수정하고, 불안해하지 않는다.

한번에 한가지에 집중

TDD 없이 개발하다 보면 상당히 머리로 상당히 많은 로직을 짜야하는데 천재개발자가 아닌 이상 어렵다.
한번에 한가지만 집중할 수 있다.

실패 테스트 만들고 패스를 하면 그 다음 입력과 출력에 집중, 로직 구현 집중, 테스트 통과 위한 어떠한 행위 허용.

대부분의 개발자들은 동시에 같이 하려고 한다.
복잡한 요구사항에서 설계를 고민하면 굉장히 어렵다.
처음부터 완벽한 설계를 하는 것이 아니라, 점진적으로 설계를 개선할 수 있다.

빠른 피드백

초반에는 피드백에 시간이 좀 걸리지만 점차 버그를 찾는 시점이 빨라진다.

서비스 안정성이 높아짐

버그 발생 가능성이 줄고, 코드 품질 향상

개발자 역량 강화

학습 효율 높아짐, 핵심 비지니스 로직 구현에 집중

구현이 완성되면 심리적 안정감이 생겨 창의력이 생김
구현부터!!!!!
설계부터 하면 압박감 때문에 잘 못함 설계를 고민하지 않아도 된다.

완벽한 설계에 많은 시간을 투자하면 나중에 변경될 때 아까워서 집착한다.
소프트웨어는 말랑말랑~

➕ 기능 추가 삭제 변경 빼고는 리팩토링이다
리팩토링은 새로운 테스트 케이스가 추가되지 않아야 한다.

내가 할 수 있는 부분까지만 설계 (초반 설계 조금)하고 TDD를 해야한다.

❓ 기능 단위 하나 -> test -> 구현 / 전체 test -> 구현 ?
선호하는 방식을 찾아라 ~

❓ 설계는 실제 클래스 구현으로 볼 수 있는지? 아니면 따로 문서로 정리한 것을 설계로 볼 수 있는지?
UML이라는 클래스 설계가 있다.
여러가지 다이어그램이 있는데 요구사항 복잡도에 따라 다이어그램 있는게 좋다.
별도의 문서 (다이어그램)이 있는게 좋다.

TDD 이게 맞나? 긴가민가하겠지만 “원래 처음에 경험하는 거다 이런거~ 당연한 거임”

“계속 도전할 것이 있어야 즐거운 것”

어디서 어떻게 시작해야할지 모르겠다

이때 요구사항 분석 및 설계를 하라

• 객체 추출
• 핵심 도메인 영역 집중 설계

Controller와 View는 아직, 도메인 설계에 집중해라.
도메인에 대한 테스트 코드를 먼저 만들어라

자동차 TDD

테스트 가능한 부분 찾아 단위 테스트

테스트하기 어려운 부분 찾아 가능한 구조로 개선

• 랜덤 값에 따라 전진

이럴 때는 오브젝트 그래프에서 의존 관계를 가지지 않는 마지막 노드를 먼저 찾는다.
이게 아무런 의존 관계가 없는…
그럼 이게 테스트 하기 쉽다면 전체가 테스트 쉽다.
테스트 영역이 많아진다.

마지막 노드가 테스트하기 쉬워야 한다.
어려우면 전체에서도 테스트 영역이 줄어든다.
테스트하기 어려운 의존 관계를 상위로 끌어 올리자.
그렇지만 언젠가는 테스트하기 어려운 코드는 나올 수 있다.

❓ 테스트 어려운 노드 최대한 상위로? 아니면 적절 단계에서 멈춤?
무조건 최상위가 아닌 적정한 단계 까지만이 좋다.

TDD 과정

TDD는 작은 단위로 시작해야지 편하다.

컴파일 에러를 해결하기 위해 클래스, 메소드 만든다 .
(맥 기준 옵션 + 엔터)

포비는 한 메소드를 완벽히 구현 했을 때 커밋한다.
컴파일 안되는 건 커밋하지 말자.
커밋하고 리팩토링 연습 해도 됨.
테스트 코드에 대한 리팩토링도필요하다.

이때 설계를 고민해라.
여기서 move가 랜덤 값에 의존하지 않도록 랜덤 값을 받는 방식으로 바꾸자!
사실 이렇게 생각하는게 쉽지는 않음 그러면 리팩토링할게 생각나고 이럼 ㅋ

리팩토링은 테스트케이스 변경이 없다!

필드로 중복되는거는 이렇게 빼자

❓ 프로덕션 작성하면서 리팩토링 보이면 일단 참고 테스트하고 리팩토링?
TDD는 한번에 한가지만 집중이니까 보인다면 문서에 일단 적어두자!
TDD는 todo를 만들어라

• todo
• done

TDD를 하다보면 설계가 완전히 달라질 수 있다.

(메서드 추출 단축키 : 옵션 + 커맨드 + m)

어떻게 테스트 가능하게 만드나?
고민하다 보면 기존 설계와는 완전히 다른게 나올 수 있다.
랜덤 배열을 전달할수도 있고. . .
여러 설계를 고민할 수 있다.