[도서 리뷰] 임베디드 C를 위한 TDD

TDD를 실제로 해보면 매우 유용하고 새로운 느낌을 얻을 수 있다. 하지만 임베디드 C와 같은 특수한 소프트웨어나 펌웨어에서는 적용하기 다소 어렵다. 그래서 이 책은 그런 부분들을 어느 정도 가이드해 준다.

 

http://www.yes24.com/Product/Goods/8117533

임베디드 C를 위한 TDD - YES24

 

테스트 주도 개발

왜 TDD가 필요한가? 사람은 실수를 하기 때문이다.

프로그래밍은 매우 복잡한 활동이며 우리가 의도한 대로 계속 잘 동작하도록 지켜줄 자동화된 테스트 케이스를 만드는 방법이다.

테스트 주도 개발이란? 점진적으로 소프트웨어를 개발하는 기법이다.

 

실패하는 테스트를 먼저 작성하지 않고는 제품 코드를 작성하지 않는다.

 

 

TDD 사이클

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

 

 

TDD의 이득

• 버그 감소
• 디버깅 시간 단축
• Side effect 감소
• 거짓말하지 않는 문서들
• 마음의 평온
• 더 나은 설계
• 진척 모니터
• 재미와 보상

 

 

임베디드 환경에서의 이득

하드웨어가 준비되지 전에, 혹은 여유분이 없을 때 하드웨어 독립적으로 제품코드를 검증함으로써 위험요소를 줄인다.

개발 시스템 상에서 버그를 해결함으로써 이후 시간이 오래 걸리는 작업의 횟수를 줄인다.

타깃 하드웨어상의 디버그 시간을 줄인다.

하드웨어와 소프트웨어 간의 상호작용을 테스트에서 모델링함으로써 상호작용 문제를 분리시킨다.

모듈화를 통해 설계를 개선한다. 테스트하기 쉬운 코드는 모델화가 잘 된 코드다.

 

 

임베디드 TDD 전략

타깃 하드웨어 병목

프로젝트 후반이 되어서야 하드웨어가 준비되어, 소프트웨어 테스트를 지연시킨다. 하드웨어는 비용이 많이 들고 수량이 부족하다. 하드웨어와 소프트웨어 문제가 섞이고 서로 손가락질한다.

듀얼 타기팅 : 최종 하드웨어와 개발 시스템 적어도 2개의 플랫폼에서 동작하도록 설계한다.

 

 

결론 및 정리

• 사람은 실수하기 때문에 테스트가 필요하다.
• TDD는 점진적으로 개발하는 방법이며 문제해결을 위한 방법이다.
• 테스트 통과하면 기분이 좋다!
• 구멍 안에 있는 자신을 발견하면 파는 일을 멈춰라.
• 문제와 거리가 멀어질수록 이상주의가 늘어난다.
• 단위 테스트가 모든 버그를 찾아낼 수는 없더라도 많은 실수들을 예방하는데 도움을 주어서 이후 상위 수준의 테스트에서는 그에 걸맞은 테스트를 할 수 있게 된다.
• 좋은 아키텍처가 비싸다고 생각하면 나쁜 아키텍처를 써봐라.

 

임베디드에서 TDD를 적용하는 주된 목적은 하드웨어를 모델링하여 개발 초기에 소프트웨어 자체 품질을 높여서 전체적인 위험부담을 줄이고 유지보수를 좋게 하여 임베디드 소프트웨어의 수명을 늘리는 데 있다고 생각한다.