⚒️

TDD, BDD, Clean Code, Refactoring

테스트를 알아야 하는 이유

TDD라는 말을 들어봐서 적용해보고 싶다면? 클린코드가 무엇인지 기준을 잡아보고 싶다면? 리팩터링은 언제, 어떻게 하면 좋을지 알고 싶다면?

이 문서를 보고 나면

TDD로 간단한 counter 기능을 구현할 수 있다.

클린코드로 나아가기 위한 리팩터링 기준점을 스스로 만들어 나갈 수 있다.

1. TDD(Test Driven Development)

TDD는 테스트를 먼저 작성하고 그 후 실제 코드를 작성하는 방법입니다. TDD는 켄트 백(Kent Beck) 이 널리 알린 개념입니다. 흔히들 개발전에 테스트 코드를 짜는게 TDD라고만 생각할 수 있는데, 그보다 본질적인 의미는 문제를 정의하고, 그 해답을 찾아가는 과정이라는게 TDD의 기본 취지입니다. 그리고 테스트도구는 그 철학을 이행하는 도구입니다. TDD는 주로 개발 코드를 유닛으로 구현합니다. 코드의 기능을 검증하는게 중요한 목표

장점

테스트를 먼저 작성하기 때문에 전체 코드에서 얼마나 많은 코드가 테스트되는가를 측정하는 테스트 커버리지 비율이 자연스럽게 높아진다.

테스트 되는 것만 코드로 작성하므로 코드가 방대해지지 않는다.

버그때문에 발생하는 시간 낭비 줄여주고, 코드가 원하는 바를 명확히 달성하는지 쉽게 확인

방법

테스트를 먼저 작성한다. 만족하는 코드가 없는 상태이므로 테스트는 실패함

테스트를 통과하는 코드를 작성한다.

리팩터링: 중복이 보이거나 더 개선할 방법이 있다면 코드를 개선한다.

3대 원칙 - 로버트 C. 마틴 (밥 아저씨, 클린 코더)

실패할 테스트를 작성하기 전에는 아무런 프로덕션 코드도 작성하지 않는다.

실패할 테스트 말고는 작성하지 않는다.

현재 실패한 테스트를 만족시키는 코드 외에는 작성하지 않는다.

좋은 테스트의 조건

•

실행 속도가 빨라야 함.

•

내부 구현(테스트하지 않는 부분)을 변경했다고 해서 테스트가 실패하면 안된다. 인터페이스(입출력 위주)를 중심으로 작성.

•

버그를 찾을 수 있어야 한다. 만들었다고 끝이 아님 테스트 시나리오를 잘 설정해야 함.

•

테스트 결과에 일관성이 있어야 한다. 코드가 변하지 않았다면 테스트 결과는 항상 동일 해야 한다.

•

의도가 명확히 드러나야 한다.

2. BDD(Behaviour Driven Development)

BDD에서는 테스트 케이스 자체가 요구사양이 되도록 개발합니다. 그래서 유저 스토리를 먼저 작성해야 하는데요. TDD에 대한 코칭을 하던 BDD의 아버지 댄 노스(Dan north)는 TDD에서 다음과 같은 벽에 마주쳤었습니다.

프로세스의 어디서부터 시작해야 하는가(Where to start in the process).

무엇을 테스트하고 또 무엇을 하지 말아야 하는가(What to test and what not to test).

한 번에 얼마만큼 테스트해야 하는가(How much to test in on go).

테스트를 어떻게 명명해야 하는가(What to call the tests).

테스트가 실패하는 이유에 대해 어떻게 이해해야 하는가(How to understand why a test fails).

이에 댄 노스와 그의 동료들은 하나의 템플릿을 만들어 채택했는데 아래와 같았습니다.

특정 값이 주어지고(Given)

어떤 이벤트가 발생했을 때(When)

그에 대한 결과를 보장해야 한다(Then).

댄 노스는 TDD 코칭을 하던 시절 ‘Test’라는 단어를 사용하지 않는 편이 사람들이 좀더 TDD의 원리를 이해하는 데 도움될 것이라 생각했고, Test라는 개념보다는 ‘Behaviour’라는 개념을 썼을 때 테스트 유닛의 의도가 좀더 명확해진다는 것을 깨달았다고 합니다. 그리고는 모든 테스트 메소드명에 ‘should’를 넣기 시작했습니다.

should는 영문법에서 어떤 행위를 기대한다는 조동사입니다. 이를 사용함으로써 개발자는 더 이상 테스트 메소드를 작성할 때 어떻게 명명해야 하는지 혼란을 느끼지 않아도 되고, 이로써 테스트 유닛에 기대되는 행위들이 명확해졌습니다. 또한 작성하는 코드가 기대하는 행위에 맞지 않는다면 이는 리팩토링의 징조가 되기 때문에 리팩토링을 통해 모든 구현 코드의 의도 또한 명확해집니다.

앞서 진행한 계산기 미션을 예로 들어보겠습니다.

스토리

Given (주어진 환경)

•

유저에게 계산기 화면이 렌더링 된 후

When (행위)

•

유저가 숫자 4을 클릭한다.

•

유저가 + 버튼을 클릭한다

•

유저가 2를 클릭한다.

•

유저가 = 을 클릭한다.

Then (기대결과)

•

계산기 화면에는 6이라는 숫자가 보여진다.

이런 유저의 행위를 그대로 테스트코드를 이용하여 재현합니다. 이처럼 BDD는 행위를 중점으로 기술하면서 테스트를 하는건데, 사실상 TDD와 사이클은 비슷합니다. 그래서 혹자는 BDD를 잘된 TDD라고 표현하는데요. 결국 중요한건 문제를 정의하고, 그 해답을 찾아가는 과정 이라는겁니다.

3. 클린 코드, 좋은 코드란

1. 사람이 읽기 좋아야 함

2. 간결하고 의도가 명확해야 함. 가능하다면 주석 없이 코드 만으로도 의도가 충분히 드러나도록 작성

3. 가능하면 의존성이 적은 코드

•

2016년에는 문자열의 길이가 주어진 숫자보다 작으면 공백 또는 전달한 문자를 채워넣어서 길이를 맞춰주는 모듈이 있었는데 개발자가 프로젝트를 다 지워서 의존성을 가진 수많은 모듈들이 작동을 멈춘 사건이 있음

•

"11줄의 코드, 인터넷을 패닉에 빠뜨리다" 내용 참조

4. 하나의 함수, 메소드, 클래스는 각각 명확한 하나의 책임만 가지기

•

접속사 없이 한 문장으로 설명할 수 없다면 다시 한번 고민해보는 것이 좋다.

•

반복문, 조건문이 많아질수록 한 문장으로 표현하기 어려우므로 분리하자.

4. 리팩터링

유명한 개발자 마틴 파울러는 리팩터링을 이렇게 정의했습니다.

소프트웨어의 겉보기 동작은 그대로 유지한 채, 코드를 이해하고 수정하기 쉽도록 내부 구조를 변경하는 기법
마틴 파울러, 리팩터링 2판, 한빛미디어

이런 리팩터링은 언제하면 좋을지에 대해서는 각자 다른 기준이 있을 수있는데 리팩터링 2판에서 마틴 파울러의 동료인 돈 로버츠의 경우에는 아래의 단계로 진행한다고 합니다.

처음에는 그냥 한다.비슷한 일을 두 번째로 한다면(중복이 생겨 당황스럽겠지만) 그래도 일단은 그냥 진행한다.비슷한 일을 세 번째 하면 리팩터링한다.

리팩터링을 진행하기 전에 체크할 사항

테스트 케이스!

리팩터링을 하면서 기존에 되던 기능이 동작하지 않는다면 리팩터링 하는 의미가 없습니다. 리팩터링은 기존의 동작은 그대로 유지한채 코드를 이해하고 수정하기 쉽도록 내부 구조를 변경하는 기법입니다.

리팩터링 대상(Code Smell)

나쁜 코드에서는 악취가 난다고 하고 이를 Code Smell이라고 부르기도 하는데요. 켄트 백과 마틴 파울러가 90년대 사용해서 유명해진 용어입니다. 혹시 자신의 코드, 그리고 페어와 함께 작성하는 코드에서 이러한 Code Smell이 나지 않는지 체크해보세요.

너무 큰 함수나 클래스

이름이 명확하지 않은 함수나 변수 이름.

중복 코드: 같은 일을 하는 코드가 여기저기 산재해있으면 수정

전역 변수: 가능하면 함수 내 혹은 모듈 내에 두자

과도한 콜백. 조건문 중첩

과도하게 긴 식별자

리팩터링 하기 전에 테스트 케이스부터 작성하자. 현실에선 테스트 케이스없는 코드를 만나기가 더 쉬움.

리팩터링 방법 예시

1. 재사용성을 위한 함수 분리

function showTodos() {
    const todos = getTodos();
    ...
    todos.forEach(todo => {
        console.log(todo);
    });
    ...
}
JavaScript
복사

위 코드는 아래와 같이 분리될 수 있습니다.

function logTodos(todos) {
    todos.forEach(todo => {
        console.log(todo);
    });
}

function showTodos() {
    const todos = getTodos();
    ...
    logTodos(todos);
    ...
}
JavaScript
복사

2. 중간 변수 도입: 의미가 명확해진다면 변수명은 길어도 괜찮습니다.

const todos = getTodos();
todos.map(todo => {
    if (todo.completed) {
        ...
    }
})
JavaScript
복사

const todos = getTodos();
const completedTodos = todos.filter(todo => todo.completed)

if (completedTodos) {
    ...
}
JavaScript
복사

복잡한 계산이 필요하다면 함수로 분리하면 좋습니다.

3. 빠른 실패: fast fail

빠른 실패를 하게끔 코드를 구현하면 depth를 줄일 수 있습니다.

if (성공로직) {
    ...
}

// 아래와 같이 빠른 실패를 하면 코드의 의도와 예외 조건이 명확해지고 나중에 분리하기도 쉽습니다.

if (실패로직) {
    return
}
... // 성공 로직
JavaScript
복사

4. 반복문 보다는 파이프

•

반복문 보다는 파이프를 이용한 경우 보다 읽기 좋은 코드가 될 경우가 많습니다.

const completedTodos = [];
for (const todo of todos) {
    if (todo.completed) {
      completedTodos.push(todo);
    }
}

const completedTodos = todos.filter(todo => todo.completed);
JavaScript
복사

5. switch 대신 object literal

function translateStatus(status) {
  switch(status) {
    case 'all':
      console.log('모두')
      break
    case 'active':
      console.log('해야할 일')
      break
    case 'completed':
      console.log('완료한 일')
      break
  }
}

//아래와 같이 object로 관리하면, 수정 및 관리에 있어서 더욱 간편해집니다.

function translateStatus(status) {
  const statusList = {
    all: '모두',
    active: '해야할 일',
    completed: '완료한 일'
  };
  console.log(statusList[status])
}
JavaScript
복사

6. 배열이나 객체는 forEach보다는 map을 이용해 불변 객체처럼 다루기

불변 객체로 다룬다면 데이터의 변화를 추적하기도 쉽고, 예상치 못한 데이터의 변경을 예방할 수 있습니다. forEach의 경우 기존 배열이나 객체에 변경을 가하는 메서드이기 때문에, forEach를 반드시 써야하는 경우가 아니라면 새로운 배열을 리턴하는 map을 활용해주세요~!

const menus = ['에스프레소', '카페라떼', '프라푸치노', '블랙티'];
menus.forEach((value, index) => {
    menus[index] += '디카페인';
});
console.log(menus);

to

const menus = ['에스프레소', '카페라떼', '프라푸치노', '블랙티'];
const decMenus = menus.map((value, index) => menus[index] += '디카페인');
console.log(decMenus);
JavaScript
복사