🤸🏻‍♂️ 우당탕탕 TDD 적용기

TDD, 그게 뭔데,, 어떻게 하는건데,,

TDD 학습정리

TDD (Test Driven Development): TFD(Test First Development) + 리팩토링

• TDD란 프로그래밍 의사결정과 피드백 사이의 간극을 의식하고 이를 제어하는 기술.
• TDD의 아이러니 중 하나는 테스트 기술이 아니라는 점입니다. TDD는 분석 기술이며, 설계 기술이기도 합니다.

TDD를 하는 이유

• 잘 동작하는 깔끔한 코드 확보
• 디버깅 시간을 줄여줍니다.
• 동작하는 문서 역할을 합니다.

그래서 어떻게 하는건데,,

1. feature 작성 및 이에 대한 테스트 시나리오 구상.
2. 2를 바탕으로 테스트 코드 작성 (최초 작성 시에는 무조건 fail일 것임)
3. 업무 코드 작성
4. 테스트 통과 시 리팩토링

1 ~ 4 반복

현재 작성 시점에서는 1까지 완료한 상태임!

고민

1. TDD를 적용 범위는 어떻게 정할까?

• 기본 정렬 알고리즘에만 적용하자!
  • 복합 정렬 알고리즘의 경우, 기본 정렬이 완벽하다면 문제 없이 수행될 것이기 때문.
  • 프로젝트의 핵심 feature가 TodoList 정렬이기 때문에, 시간/비용을 고려하여 core logic에만 TDD를 적용하기로 했다.

기본 정렬 알고리즘

• 정렬조건 당 function 1개 선언을 가정하고, function 하나 당 하나의 테스트 케이스를 만든다.
• '오늘 당장 처리해야 하는 일' > 각 Todo의 중요도가 높은 순 정렬 > Deadline이 빠른 순으로 정렬

Category	Type	Task	Description
알고리즘(TDD)	기본 정렬 테스트	Imminence 정렬	다른 조건이 모두 동일하다면, Imminent Todo가 Active된다.
알고리즘(TDD)	기본 정렬 테스트	Importance 정렬	다른 조건이 모두 동일하다면, Importance가 높은 Todo가 Active된다.
알고리즘(TDD)	기본 정렬 테스트	EDF 정렬	다른 조건이 모두 동일하고, Deadline이 빠른 Todo가 Active된다.

복합 정렬 알고리즘

• 정렬 함수가 제대로 호출되었는지 수준으로만 테스트케이스를 작성한다.

• 복합적인 상황이란, 동적인 변화가 생겼을 때 정렬 기준에 맞게 정렬이 올바르게 적용되었는지 확인하는 작업이다.

• 이 경우, 정렬 함수가 올바르게 설계되었다면 큰 이상이 없을 것으로 판단되므로, 제한적으로 함수가 호출되었는지 확인하는 수준으로 테스트한다. TDD를 완전히 적용한다기 보다는, 개발자가 직접 확인하는 것을 기본으로 한다.

• 예시) 오늘 당장 해야 하는 일을 모두 끝내면 TodoList에 남아있는 항목 중 가장 우선순위가 높은 일을 최우선으로 보여준다.

Category	Type	Task	Description
알고리즘	복합	CREATE	Imminent Todo List가 비어 있는 상황에, Imminent Todo를 추가한다. 이 경우, 새로 생성된 Todo가 Active된다.
알고리즘	복합	CREATE	Imminent Todo List에 Todo가 1개 이상인 상황에 Imminent Todo를 추가한다. 이 경우, Imminent Todo List 중 Importance가 가장 높은 Todo가 Active된다.
알고리즘	복합	DELETE + 순서관계	Imminent Todo List가 비어있고, Distant Todo List의 Todo가 2개 이상일 때 Active Todo를 제거하면 다음 Todo가 Active된다.

진행 방식

• Test Code 작성 후 성공 100%되게끔 만들자
• 처음에는 100% fail
• 한 항목씩 success를 늘려나가자구!

2. 테스트 대상이 되는 함수 스펙을 어떻게 정의할 것인가?

고민이 시작된 이유

회의 중 아래의 세 가지 관점들이 언급되었고, 어떤 방식으로 함수를 정의하고 테스트할 것인지에 대한 토론이 시작되었다.. 이에 따라 아래에 이어서 나오는 두 가지 방법이 논의 대상이 되었다.

• 관점 1: 테스트 코드를 작성할 때 좀더 수월하게 혹은 가독성 좋게 하기 위해 함수(혹은 method)의 스펙을 어떻게 정할까?
• 관점 2: 우리가 실제 코드를 작성할 때 함수 혹은 method가 어떻게 생겨먹어야 더 간결하고 가독성 좋게 작성할 수 있을까?
• 관점 3: TDD가 점진적으로 refactoring하는 방법이므로 우리가 일단 정하고 테스트를 진행하면서 이를 정해야하는 것이 아닐까?

공통

• 공통 전제
  1. 전체 Todo List는 State로 관리한다.
  2. 모든 function은 원본 데이터를 수정하지 않도록 작성한다. (불변성 준수)
• 공통 코드

interface Todo {
  id: string;
  importance: number;
}

const todo1: Todo = {
  id: 'id',
  importance: 3,
};

const todo2: Todo = {
  id: 'id',
  importance: 2,
};

1) TodoList Class 먼저 선언 후 테스트

class TodoList {
  todoList: Array<Todo>;

  constructor(initialTodoList: Array<Todo>) {
    this.todoList = initialTodoList;
  }

  sort(): TodoList {
    return new TodoList(
      [...this.todoList].sort((x, y) => {
        return x.importance - y.importance;
      }),
    );
  }
}

function App() {
  const [todoList, setTodoList] = useState(new TodoList([todo1, todo2]));

  useEffect(() => {
    // sort 진행 시
    setTodoList((prevTodoList: TodoList) => {
      return prevTodoList.sort();
    });
  }, []);

  return (
    <div>
      Hello World!
    </div>
  );
}

장점

1. 함수 import를 줄일 수 있다.
2. todoList.pop().sort(); 와 같이 체이닝하여 사용할 수 있다.
3. todoList라는 parameter를 매번 넘기지 않아도 된다.

단점

1. 미리 선언해두었다가 클래스의 구조가 변경되면 다시 선언해야 할 수 있다.
2. 테스트 시 복잡할 수 있다.

expect(new TodoList([todo2, todo3, todo1]).sort()).toEqual(new TodoList([todo1, todo2, todo3])); //..? 확실하진 않음

장단을 파악하기 어려운 부분

• todoList를 관리하는 함수들(sort, update 등)이 class 내에 선언되어 있으므로 강결합인 건 아닌지 고민된다. (?)

2) 기능 당 함수 하나씩 선언 후 테스트

const MANAGE_TODOLIST = {
  sort: (initialTodoList: Array<Todo>) => {
    return [...initialTodoList].sort((x, y) => {
      return x.importance - y.importance;
    });
  },
};

function App() {
  const [todoList, setTodoList] = useState([todo1, todo2]);
  useEffect(() => {
    // sort 진행 시
    setTodoList((prevTodoList: Array<Todo>) => {
      return MANAGE_TODOLIST.sort(prevTodoList);
    });
  }, []);
  return (
    <div>
      Hello World!
    </div>
  );
}

장점

1. 테스트 코드/데이터가 단순하다. (단순 배열로 테스트 데이터를 구성할 수 있다.)

expect(sort([todo2, todo3, todo1])).toEqual([todo1, todo2, todo3]);

2. 정말 함수형 프로그래밍같다(?)

단점

1. 체이닝이 불가능하다. (확장성에 불리할 수 있다.)
2. 매번 todoList를 parameter로 넘겨야 한다.
3. (능 추가) interface간 연관관계가 있다면 관리가 어려워진다. (sortTodoList(todoList: TodoList)가 todoCompare(todo: Todo)를 활용한다면, sortTodoList가 선언되는 모듈에서는 TodoList, Todo, todoCompare를 각각 import해야만 한다... (class method 방식은 TodoList와 Todo 모듈만이 존재))

추가로 논의했던 내용들

FP와 OOP는 서로 배척하는 개념이 아니다.

• 앞서 논의했던 class로 관리하는 TodoList 역시 내부 함수를 순수함수로 작성하면 FP + OOP의 장점을 모두 누릴 수 있을 것이다.

(능 추가, 어디넣을지 모르겠음) 테스트의 관심사가 결국 중요하다.

• 결국은 테스트의 관심사가 제일 중요하다. 질문의 의도는 약간 고민과 다르지만, 순수 함수가 암시적 의존이면 (테스트 등에) 안 좋냐는 StackOverflow 질문에 달린 대부분의 답글을 보면 의존성을 왜 신경씀? 이라고 대부분의 답변자가 코멘트했다. 요컨데 테스트하고 싶은 기능이 TodoList의 정렬이라면 Todo에 의존하는 것은 당연하고, 그 이상의 의존성 분리는 애초에 테스트의 관심사가 아닌데 왜 신경을 쓰느냐는 관점이 많았다.

느낀점

TDD를 계획하면서 테스트 케이스(시나리오)를 작성하다 보니 알고리즘 설계가 좀 더 견고해졌다.

• 팀원들끼리의 생각을 일치시킬 수 있었고, 서로 다른 생각을 가진 부분을 합의하는 데 더 수월했던 것 같다.
• 서로 예외 케이스를 공유하면서 알고리즘을 좀 더 견고하게 만들었고, 우리 프로젝트에 대한 팀원 각자의 이해도 역시 향상될 수 있었다.
• TDD는 분석 기술이자, 설계 기술이 맞는 것 같다..?