골드에그

오늘의 공부 영상은 아래 영상입니다. 원본 영상은 아래 링크를 참조해주세요~

TDD 는 Test Driven Development 의 약자로 "테스트 주도 개발"이라고 한다. 작은 단위의 테스트를 먼저 작성하고 그 테스트를 통과하는 코드를 지속적으로 추가하면서 짧게 개발하는 애자일 방법론 중 하나이다.

TDD 사이클은 위 그림과 같다. INITAL TEST 단계부터 시작해서 REFACTOR CYCLE 까지 순차적으로 반복 수행한다.

INITAL TEST 단계에서는 실패하는 테스트 코드를 먼저 작성한다. 다음 단계 가기 전까지 실제 로직에 들어가는 코드를 작성하면 안 된다. CODE 단계에서는 테스트 코드를 성공시키기 위한 실제 로직을 작성한다. REFACTOR CYCLE 단계에서는 중복 코드 제거, 일반화 등 리펙토링을 수행한다.

먼저 실패하는 테스트 코드를 작성하는 것은 어렵게 느껴지지 않는다. 요구사항에 주어진 입력과 출력의 경계라던지, 요구사항에 주어진 규칙에 반대되는 코드들을 작성하면 된다. 그런데 막상 해보면 알고리즘 문제에서 주어지는 통합환경에서의 테스트 정도다.

이 정도의 테스트만 해도 될까? 더 해야 되는 테스트가 있을까? 그런 생각을 하던 찰나에 위 영상을 보게 되었다.

영상에서는 처음부터 TDD 를 의식하지 말고 아래와 같은 규칙을 만들면서 코딩 연습을 해보라고 권장하고 있다.

코드 컨벤션을 지키면서 프로그래밍한다.

(자바의 경우, Google Java Style Guide)

한 메서드에 오직 한 단계의 들여쓰기만 한다.

함수 또는 메서드가 한 가지 일만 할 수 있도록 작게 만든다.

else 예약어를 쓰지 않는다.

모든 원시값과 문자열을 포장한다.

한 줄에 점을 하나만 찍는다.

불필요하게 공백 라인을 만들지 않는다.

공백 라인을 띄우는 것도 의미있게 띄우자.

줄여쓰지 않는다.(축약 금지)

모든 엔티티를 작게 유지한다.

3개 이상의 인스턴스 변수를 가진 클래스를 쓰지 않는다.

일급 컬렉션을 쓴다.

객체에서 데이터를 꺼내지 말고 객체에 메세지를 보내라.

Getter/Setter/Property 를 쓰지 않는다.

메서드(함수)에서 이상적인 인자 개수는 0개이다. 인자의 갯수를 3개 이하로 줄여라.

위 규칙들을 지키면서 코딩하게 되면, 자연스레 메서드와 클래스가 작은 단위로 쪼개지고 각 단위 별 테스트가 가능해진다. 마지막 문장은 클린 코드에서 본 문장이었는데 억지스러운 문장처럼 보이지만 실제로 된다. 저 내용 말고도 더 많은 내용들이 있겠지만, 오늘부터 위 내용을 반드시 지키면서 코딩해보려고 한다.

끝으로 영상 마지막 부분에 누가 강사님께 질문을 했는데 내가 직접 답변해보면서 마무리하고자 한다.

Q . TDD 로 개발하다보면 재사용성은 좋지만 같은 기능을 중복되서 작성하거나, 성능에 이슈를 가져오는 코드가 생길 수 있는데 어떻게 생각하시나요?

A . 객체지향으로 설계하다 보면 간혹 기능이 중복되는 코드들이 존재하는데 나중에 리팩토링 단계에서 합성이나 프록시 패턴으로 반복되는 구간을 함께 운영하면 좋을 것 같다. 테스트를 용이하게 작성하는 것이 제일 중요하다. 그 후 성능에 가져오는 코드들만 모아 다시 리팩토링하면 좋지 않을까 생각한다.