3장, 프로그램을 실패하게 만들기

참조 문헌

안드레아스 젤러(Andreas Zeller) 저, Why Programs Fail:프로그램은 왜 실패하는가?. 류 광역, (주)사이텍미디어 p.073 ~ p.113

참조 링크

3장, 프로그램을 실패하게 만들기 내용

디버깅을 위한 테스트와 테스트 자동화에 대해서 소개하고 있다. 아직까지는 실용적인 내용 보다는 개념적인 내용이다.

디버깅을 위한 테스트는 어떤 의미인가?

디버깅이란 문제점에 대해서, 재현하고, 단순화 시키고, 관찰하고, 수정을 확인하고, 재발 확인 과정이다. 테스트란 문제점을 드러내는 것을 목적으로 하는 행위를 뜻한다. 그러므로 디버깅을 위한 테스트가 있다면, 디버깅의 각 단계를 보다 쉽게 할 수 있다.

이러한 테스트는 자동화 하면, 더 적은 노력으로 디버깅 할 수 있다.

테스트는 어떻게 만드는가?

프로그램의 인터페이스에 따라 테스트를 만들 수 있는데, 일반적으로 프로그램에는 3가지 계층이 있고, 이 계층에 따라 테스트 방법이 다르다.

• 표현층(presentation layer)
  - 프로그램과 사용자 간에 상호작용하는 계층
  
  
• 기능층(functionality layer)
  - 프로그램의 주요기능을 감싸는 계층
  
  
• 단위층(unit layer)
  - 기능을 여러 단위로 나뉜 계층

경험적으로 유닛층만 해도 효과적이라고 생각한다.

표현층(presentation layer)에서의 테스트는 어떻게 만드는가?

키보드나 마우스의 이벤트를 발생 시키거나 캡처하고, 리플레이 툴/스크립트 등을 이용해 만들수 있다. 운영체제 마다 이 툴/스크립트가 다를 수 있는데, 책에서는 Android 스크립트, AppleScript 등을 소개 하고 있다. 개인적으로 AutoHotKey 도 할 수 있지 않을까 생각한다. 주의해야 할 점은 프로그램의 UI 등이 바뀌면, 기존에 만든 테스트가 무용지물이 되는 경우가 많다. 

기능층(functionality layer)에서의 테스트는 어떻게 만드는가?

개발할 때 부터, 프로그램의 기능들에 접근할 수 있는 인터페이스를 제공하고, 프로그램 언어를 통해 테스트 코드를 만들고 자동화 할 수 있다. 이러한 인터페이스가 있다면, 다른 스크립트 언어로도 만들 수 있다. 

단위층(unit layer)에서의 테스트는 어떻게 만드는가?

기능층과 마찬가지로 개발 할 때부터 기능에 대해 유닛을 나누고, 각 유닛별 의존성이 최소화 하며, 프로그래밍 해야 한다. 이렇게 프로그래밍이 되었다면, 유닛 테스트를 만들 수 있고, 이 유닛들을 모아 하나의 기능까지도 테스트 가능하다. 이를 자동화 하는 것은 쉽다.

의존성을 낮추는 대표적인 방법은 MVC 패턴이 있는데, 경험적으로 이러한 패턴은 자연스럽게 받아 드릴 수 있을 것이다. 

여담

경험적으로 유닛 테스트만 만들어도 매우 훌륭히 문제점을 찾을 수 있다. 하지만 기존 코드가 유닛 테스트를 적용하기 힘들게 되어 있는 경우도 많이 있다. 이럴땐 전부 적용하기 보다는 새로운 기능만이라도 적용해 두고, 조금씩 부분 격파 하는게 좋을 것이다. 그리고 코드를 컴파일 할 때, 프로그램과 유닛 테스트도 같이 하는게 더 효과적이다.

유닛 테스트 도구로는 각 프로그램 언어별로 무수히 많이 있으므로, 입맛에 맞게 고르기만 하면 된다.

:wq