[임베디드 C를 윈한 TDD] 1장 테스트 주도 개발

1. 테스트 주도 개발이란?

테스트 주도 개발은 점진적으로 소프트웨어를 개발하는 기법입니다. 개발 코드를 바로 작성하지 않습니다. 기대에 대한 테스트를 작성한 뒤 해당 테스트가 실패하는 것을 확인한 후 테스트가 성공하도록 코드를 작성하는 개발 방법입니다.

테스트 자동화는 TDD에서 매우 중요합니다. TDD를 진행할 때는 각 단계마다 자동화된 단위 테스트를 새로 만들고, 그 테스트를 만족시키는 코드를 작성하게 됩니다. 제품 코드가 늘어나면서 단위테스트도 같이 늘어납니다. 코드를 고칠때마다 테스트 모음을 실행시키면서 새로 작성한 코드의 기능이 재대로 동작하는지 확인할뿐만 아니라 기존의 코드도 여전히 잘 동작하는지 확인할 수 있습니다.

소프트웨어는 깨지기 쉽습니다. 어떠한 변경을 하더라도 의도하지 않은 결과를 가져올 수 있습니다. 만약 테스트를 수작업으로 해야된다면 모든 테스트를 수행하기 어렵습니다. 테스트를 반복하는 비용이 너무 높기 때문에 우리는 일반적으로 개발한 부분에 대해서만 테스트를 진행합니다. 이로 인해 결함이 발생했는지 모르고 제품이 릴리즈되는 경우가 생깁니다. TDD는 자동화된 테스트 적분에 의도하지 않은 결과의 검출을 쉽게 도출할 수 있습니다.

TDD 마이크로 사이클

테스트 코드를 왕창 작성하고 나서 제품코드를 작성하는 것은 TDD가 아닙니다.

TDD는 작은 테스트 하나를 작성하고, 기존에 작성해놓은 테스트를 모두 통과하면서 추가한 테스트 역시 통과하도록 코드를 작성하는 것입니다.

아래 목록은 켄트 벡(Kent Beck)의 책, 『테스트 주도 개발』[Bec02]에 설명된 TDD 를 근거로 하여 정리한 TDD 사이클의 단계입니다.

1. 작은 테스트를 하나 추가한다.
2. 모든 테스트를 실행하여 새로 추가한 테스트가 실패하는 것을 눈으로 확인한다. 컴파일이 안 되는 것조차도 실패는 실패다
3. 실패한 테스트를 통과시키기 위해 필요한 만큼만 조금 수정한다.
4. 모든 테스트를 실행하여 새로 추가한 테스트가 통과하는지 확인한다.
5. 중복을 제거하고 의도가 잘 표현되도록 리팩터링한다

TDD 사이클을 한번 마치는데에 걸리는 시간은 길어야 몇분 정도여야 합니다. 테스트와 코드는 점진적으로 추가됩니다. 코드가 새로 추가될 때 마다 작성되어있던 테스트들이 즉각적인 피드백을 주게 됩니다.

무언가를 수정할 때 마다 테스트를 실행해야 합니다. 테스트는 새로 작성한 코드가 동작하는지를 알려주면서, 수정으로 인한 의도하지 않은 결과가 생겼을 때 경고를 해줍니다.

TDD의 이득

1. 버그 감소

• 나중에 심각한 문제를 야기할 수 있는 크고 작은 논리적 오류들이 TDD를 진행하는 중에는 금방 발견할 수 있음

1. 디버깅 시간 단축

• 버그가 줄어든다는 것은 그 만큼 디버깅 시간도 줄어드는것을 의미함

1. side-effect 결함 감소

• 새로 작성하는 코드가 기존의 사양에 위배가 되면 테스트 실패로 확인이 가능해짐

1. 마음의 평온

• 철저히 테스트한 코드를 가지고 있다는 것은 자신감을 주게 됨

1. 더 나은 설계

• 좋은 설계는 테스트하기 쉬운 설계임
• 긴함수, 서로 얽혀있는 코드, 복잡한 조건식들은 모두 테스트하기 어려운 코드임
• 코드를 수정하기 위해 테스트 작성시 쉽게 작성할 수 없다면 설계적 문제가 드러난것임

1. 진척 모니터

• 어디까지 동작하고 얼마나 완료했는지를 테스트가 정확히 추척할 수 있음

임베디드 환경에서의 이득

• 하드웨어가 준비되기 전에, 혹은 하드웨어 비용이 높아 여유분이 없을 때에 하드웨어에 독립적으로 제품 코드를 검증함으로써 위험을 줄인다.
• 개발 시스템상에서 버그를 해결함으로써 타깃 컴파일, 링크, 업로드로 이어지는 시간이 오래 걸리는 작업의 횟수를 줄인다.
• 문제를 찾고 고치기가 더 어려운 타깃 하드웨어상의 디버그 시간을 줄인다
• 하드웨어와 소프트웨어 간의 상호작용을 테스트에서 모델링함으로써 상호작용 문제를 분리시킨다.
• 모듈 간, 하드웨어와 소프트웨어 간의 의존성을 낮춤으로써 소프트웨어 설계를 개선한다. 테스트하기 쉬운 코드는 모듈화가 잘 된 코드다.