ASSERT에 대해 살펴보자.
여러분은 얼마나 많이 ASSERT를 사용하나요? ASSERT를 얼마나 잘 사용했는지를 알아보기
위해서는 내 코드를 사용한 동료가 입력값을 잘못 입력했을 때, 또는 나의 모듈을 잘못 사용
했을 때 너무 많은 오류 메시지 상자 때문에 작업을 할 수 없다고 불평할 정도가 되어야 한다.
그만큼 모든 것을 Debug 빌드에서 확인할 수 있을 정도가 되어야 한다. 그렇다면 결국 우리는
''가능한 한 많이''라는 말을 머리에 항상 염두해 두어야 하겠다. 하지만 말이 아무리 좋다고
하더라도 사용하지 않으면 전혀 쓸모가 없는 법이다.
그래서 오늘은 ASSERT의 의미에 대해서 살펴보고, ASSERT를 사용하는 방법에 대해서
살펴보도록 하겠다. 이번 시간에는 C#을 다루도록 하겠다. 만약 여러분이 이 ASSERT를
제대로 사용할 줄 안다면 다른 언어(예를 들면, C++ 또는 VB .NET)에도 동일한 ASSERT
개념이 적용되기 때문에 레퍼런스를 활용하여 쉽게 활용하실 수 있을 것이다.
ASSERT는 무엇인가?
ASSERT는 프로그래머가 의도한 대로 입력 값 또는 결과가 정확하게 존재하는지를 확인
하기 위한 작업이다. 여기에서 가장 중요한 단어는 확인이다. 뒤에서 다시 한번 언급하겠지만,
ASSERT는 확인을 위한 과정이지 코드를 수행하기 위한 과정은 아니다. 만약 이에 대한 개념을
잘못 잡고 있다면 디버그 빌드와 릴리즈 빌드가 서로 다르게 작동하는 결과를 낳을 수도 있다.
ASSERT는 다음과 같이 사용한다.
Debug.Assert(조건, "오류 메시지");
만약 괄호안의 조건이 거짓이면 두번째 인자에 해당하는 "오류 메시지"를 표시한다. 매우 간단
하다. 백명중에 한명꼴로 ASSERT가 거짓인 조건을 검사한다고 이해하는 분도 있다. 그럼 완전히
반대의 상황이 발생해서 잘못된 값을 넣어주면 잘했다고 칭찬하고 제대로 된 값을 넣어주면 마구
마구 뭐라고 하는 청개구리 코드가 되어 버린다. 그런 분들이 왜 그렇게 이해했는지 얘기를 해
보니 ASSERT에 대한 개념을 외우려고 하다보니 그랬다라고 한다. 우리는 그냥 상식 선에서 생각
하자. 당연히 그게 맞는지 확인하려고하는거지, 틀린지 확인하지는 않을 것이다.
자, 그럼 간단한 예를 하나 들어보자.
public static void MyMethod(Object object)
{
Debug.Assert(object != null, "object 매개 변수가 null입니다.");
/* 작업 수행 */
}
이 코드에서는 매개 변수로 객체(Object 형식)가 넘어오기 때문에 이 객체를 사용하기 전에 null
인지 아닌지를 확인하는 코드이다. 물론 매개 변수로 넘어온 모든 객체에 대해서 null인지
확인해야 하느냐에 대한 질문에는 상황마다 다르다라고 말해줄 수 밖에 없다. 경우에 따라서
객체가 null이어도 전혀 문제가 없을 수 있기 때문이다. 하지만 기본적으로 매개 변수로 넘어온
객체를 이 메서드에서 사용한다라고 가정하고 있기 때문에, 예제와 같은 코드는 매우 흔히 볼 수
있는 ASSERT의 대표적인 경우라고 보면 되겠다. 자, 그럼 여러분은 이제 매개 변수로 넘어온
객체에 대해서 null인지 아닌지를 구분해야 한다라는 것을 알게 되었다.
ASSERT를 어떻게 사용할 것인가?
앞서 말했듯이, ASSERT는 굉장히 단순한 개념이다. 프로그래머가 확인하고 싶은 조건을 걸어두고
그냥 실행만 하면 조건에 맞지 않는 값이 들어왔을 때, 프로그래머가 디버깅을 하지 않아도 오류가
발생한 위치를 정확하게 알 수 있다. 일반적으로 ASSERT는 다음과 같은 상황에서 사용한다.
1. 내가 작성한 메서드에 넘어온 매개 변수를 확인하고 싶을 때
2. 내가 호출한 메서드에서 반환한 값을 확인하고 싶을 때
3. 내가 호출하는 메서드의 매개 변수를 확인하고 싶을 때
첫번째, ''내가 작성한 메서드에 넘어온 매개 변수를 확인하고 싶을 때''가 ASSERT를 사용하는
가장 흔한 경우이다. 앞에서 소개한 예제 코드도 바로 이런 경우에 속한다고 볼 수 있다.
이 경우에는 대부분 메서드의 코드 시작 부분에서 오류가 발생할 수 있는 모든 상황을 검증하는
것이 일반적이다. 왜냐하면 시작 부분에서 완벽하게 검증하지 않고 ASSERT 코드가 분산되어
있다면 매개 변수로 넘어온 값이 내가 작성한 코드에 의해서 영향을 받게 되어 ASSERT가 실패할
수 있기 때문이다. 이런 경우에는 비록 ASSERT로 오류가 발생하는 위치를 찾았다고 하더라도
디버깅하기 위해서 처음부터 코드를 다시 살펴봐야 하기 때문이다. 따라서 매개 변수는 함수
시작 부분에서 확인한다라고 알아두시면 되겠다.
두번째 ''내가 작성한 메서드에서 반환한 값을 확인하고 싶은 경우''는 우리가 잊어버리기가 굉장히
쉽다. 하지만 첫번째 상황보다는 ASSERT를 해야 한다라는 인식면에서 볼때 더 많이 알려진 경우
라고 볼 수 있다. 사실 프로그래머가 되면서 가장 많이 듣는 말이 리턴 값을 검사해야 한다는 말이다.
리턴 값을 넘기지 않는 함수들도 많지만, 함수가 제대로 작성되어 있다면 적어도 성공 또는 실패라는
정도는 알려주어야 한다고 생각한다. 리턴 값이 없는 함수들(리턴 값이 void인 함수들)을 작성한
프로그래머는 거의 모든 상황에서 함수가 성공하며 이 함수를 사용하는 사람은 함수의 성공 여부에
관심을 가질 필요가 없다라고 생각하기 때문일 것이다. 하지만 그건 함수를 작성하는 사람의 생각일
뿐이지, 함수가 리턴값으로 성공이라고 알려준다고 해도 전혀 해가 될것이 없고 언젠가는 함수의
결과를 확인해야 하는 순간이 올 수 있기 때문에 될 수 있으면 리턴 값을 넘기도록 함수를 작성하는
것이 좋다고 생각한다. 결국 내가 호출하는 어떠한 함수도 실패할 수 있고 내가 원하는 대로 함수가
작동하는지 확인해야 할 필요가 있기 때문에 함수의 리턴값은 함수를 호출한 다음 곧바로 검사할
수 있도록 해야한다.
마지막으로 ''내가 호출하는 메서드의 매개 변수를 확인하고 싶을 때''에는 일반적으로 자주 일어나는
경우는 아니지만, 다른 사람이 작성한 함수가 잘 작동할 수 있도록 배려하는 차원에서 확인한다고
보면 되겠다. 하지만 내가 아무리 정확하게 검증한다고 하더라도 해당 함수를 작성한 사람이 함수
안에서 내가 전달한 매개 변수를 검증하는 것보다는 확실하지 못할 것이다. 결국 첫번째 경우를
모두가 지켜준다면 세번째 경우는 필요가 없다.
출처 : 네이버 지식인
