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

TDD, 과연 무엇인가?

고민

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

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

기본 정렬 알고리즘

• 정렬조건 당 function 1개 선언을 가정하고, function 하나 당 하나의 테스트 케이스를 만든다.

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

복합 정렬 알고리즘

• 정렬 함수가 제대로 호출되었는지 수준으로만 테스트케이스를 작성한다.
• 복합적인 상황이란, 동적인 변화가 생겼을 때 정렬 기준에 맞게 정렬이 올바르게 적용되었는지 확인하는 작업이다.
• 이 경우, 정렬 함수가 올바르게 설계되었다면 큰 이상이 없을 것으로 판단되므로, 제한적으로 함수가 호출되었는지 확인하는 수준으로 테스트한다. TDD를 완전히 적용한다기 보다는, 개발자가 직접 확인하는 것을 기본으로 한다.

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. 전체 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 {
    const todoList = [...this.todoList];
    return new TodoList(
      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로 넘겨야 한다.

추가로 논의했던 내용들

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

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