반응형

어써션이란

  • 프로그램의 특정 지점에 위치한 어써션은 해당 지점에서 개발자가 반드시 참(true)이어야 한다고 생각하는 사항을 표현한 논리식이다. 어써션이 위반되는 경우(, 논리식 결과가 거짓)는 프로그램에 버그나 기타 문제가 있는 것을 암시한다.
  • 예를 들어 아래 코드는 두 개의 어써션을 포함한다. 프로그램 실행 중에 x > 0x > 1가 해당 지점에서 반드시 이여야 한다.
x := 5;
	{x > 0}
x := x + 1
	{x > 1}
 
  • 어써션은 단순히 개발자의 주석(comments) 형태로 프로그램에 포함되기도 하고 또는 프로그래밍 언어에서 컴파일 및 실행이 가능한 구문을 지원하기도 한다. 예를 들어 아래의 "assert" 매크로는 index가 특정 범위 내에 있는 경우는 실행에 영향을 주지 않는 no-op 문장으로 남아 있지만, 범위를 벗어나면 애플리케이션을 중단시키고 실패(False)한 어써션을 디스플레이 하여 프로그래머에게 알린다.

assert(0 <= index && index < length);

  • 프로그래머는 스크린 또는 로그 파일로 출력된 실패한 어써션의 진단 정보(, 실패한 어써션이 위치한 소스 코드 파일명 및 라인 번호, stack trace, 코어 덤프 등)를 참고하여 빠르게 버그 위치를 파악하고 수정할 수 있다.
  • 실패하지 않은 어써션들은 no-op 문장이므로 일단 프로그램이 충분히 테스트되고 버그 수정이 완료되면 어써션을 제외(비활성화)한 채 소스 코드를 재컴파일하여 더 가볍고 빠른 실행 파일을 생성한다(릴리즈 버전에서는 대개 어써션이 제외됨).

 

어써션의 한계(Limitations)

  • 어써션은 프로그램에서 버그를 빠르게 식별하여 더 효과적인 테스팅이 가능하도록 돕지만 실행되지 않는 어써션은 전혀 도움이 되지 못한다. , 어써션은 자신을 포함하는 코드 경로가 실행되는 경우에만 유용하다.
  • 어써션이 프로그램 로직에 영향을 미치지 않도록 고안되었다 하더라도 메모리 데이터나 쓰레드 타이밍을 변경함으로써 성능에 예상치 못한 영향을 줄 수 있으므로 신중하게 구현되어야 한다.
  • 어써션 자체도 버그로부터 자유롭지 못하므로 존재하지 않는 에러를 보고하거나 반대로 존재하는 버그를 보고하는데 실패하는 일이 있을 수 있다(부적절하게 사용되는 경우 개발자/테스터의 일을 돕는 대신 오히려 방해하는 요인이 되기도 함).

 

테스트 프레임워크에서 어써션

대부분의 자동 테스트 프레임워크에서 테스트는 예외(exception)가 발생하지 않는 한(, 실행할 때 에러가 발생하지 않는 한) 해당 테스트가 "통과"된 것으로 간주한다. 그러나 테스트 마지막에 일종의 검증(예, 테스트한 작업의 실제 결과를 특정 예상 결과와 비교)을 수행하는 것이 모범적인 테스트 관행이다. 이러한 이유로 대부분의 테스트 프레임워크가 어써션이라고 하는 간단한 메커니즘을 통해 이러한 검증(verifications) 수단을 제공한다.

일반적인 Assert 문은 사용자(테스터)가 실제 결과를 예상 결과와 비교하도록 허용하며, 이 비교가 실패하는 경우 예외를 발생시키고 테스트 결과를 "실패(Failure)"로 반환한다. 대부분의 테스트 프레임워크가 자신의 고유한 어써션 메쏘드를 함께 제공한다. 또한 HTTP 응답 메시지 유효성 검사 같은 보다 특수한 어써션 방법을 제공하거나 또는 사용자가 직접 정의할 수 있는 확장가능한 어써션을 제공하기도 한다.

 

반응형

+ Recent posts