TDD 에 익숙해지기 위해서는 생각의 전환, 사고의 전환이 필요한 것 같다.
TDD 를 접하기 전에 나는 구현해야 하는 프로그램이 있다면 제일 먼저 클래스를 만들었다. 프로그램 안에서 송금 기능을 구현해야 한다고 하면, 일단 계좌 객체를 만든다. 계좌 객체에 잔액 변수를 선언하고 초기 금액을 집어 넣는다. 만약 송금 기능 안에 조금 더 디테일한 송금을 위한 요구사항이 들어있다면 이제 모니터를 바라보며 무한한 고민의 늪에 빠진다.
분명 효율적인 방법은 아니었으나 TDD 를 접하기 전에는 이런 방식으로 진행했었다. 하지만 테스트 주도 개발 방식은 이것과는 다르다. 상태 속성과 실제 메서드를 구현하기 전 냅다 테스트 클래스를 만든 후 거기서 제일 작은 요구사항부터 하나씩 하나씩 실패 후 성공하는 코드를 만든다. 테스트 코드를 만들 때는 클래스의 속성보다 클래스의 동작에 먼저 집중하기 때문에 상태와 속성은 나중 이야기이다. 어떤 속성을 넣어야 하는지 고민하기 보다 '어떤 동작이 필요하니까 거기에는 이 속성이 들어가야겠구나!' 라고 생각해야 한다. 생각해보면 당연한 이야기이고 초반부터 오류를 미리 막아주니 고맙기까지 한 방식이다.
하지만, 클래스를 만든 후 제일 먼저 속성부터 선언하고 고민하던 평소 습관과 아예 반대되는 방식으로 해야 하다보니 아직도 너무 헷갈리는 부분이 많다. 이번 4주차 과제가 한 개 더 남아있고 현재 작업중인데 자꾸 속성부터 선언하려는 손을 억지로 (ㅋㅋ) 막고 있다. 이렇게 고민한다는 건 가이드를 따라하지 않았다는 반증이다. 요구사항을 작게 작게 쪼개서 그것부터 테스트를 해야 하지만 자꾸 제일 큰 요구사항에 집중하고 있다. 다음 주 평일부터 진행될 개인 프로젝트를 위해 무조건 내일 오전까지는 끝내야 한다. 작은 요구사항에 집중하자!!!
'TIL' 카테고리의 다른 글
시간 분배능력 무슨일임... (22.09.19 TIL) (0) | 2022.09.19 |
---|---|
다른 관점으로 유도하는 유익한 습관 (22.09.18 TIL) (1) | 2022.09.18 |
Bounded Context (22.09.16 TIL) (0) | 2022.09.16 |
TDD 한테 피드백 받기 (22.09.15 TIL) (0) | 2022.09.15 |
문제-해결-반성의 성장 싸이클 (22.09.14 TIL) (0) | 2022.09.14 |
댓글