[CS] 엣지 케이스와 코너 케이스는 뭘까?(feat.. 조금 더 안정성 있는 서비스를 향하여..)

학습 계기

유데미의 Java 강의에서 객체지향 코드 케이스를 작성하다가, 엣지케이스라는 용어를 마주했다. QA관련해서 API의 테스트코드를 작성 하면서 그리고 정보처리기사를 공부하면서 몇 번 들었던 용어인데 제대로 정리를 해본적이 없는 것 같아 이번 기회에 정리해보고자 한다.

이번 학습으로 인한 기대 효과

API를 짜오면서 테스트를 진행하고자 할 때, 단순히 '성공하는 테스트’와 '명확하게 실패하는 테스트’뿐 아니라 **‘문제가 될 수 있는 부분을 검증하는 테스트’**도 진행해보고싶었는데, 대체 어떤 부분을 어떤식으로 작성해야하는지 막막했던 적이 있었다. 이번 학습을 통해 엣지 케이스와 코너 케이스 같은 용어를 공부하고, 어떤식으로 엣지 케이스를 세울 수 있는지 배워서 조금 더 안정성 있는 서비스를 만드는 개발자에 가까워 질 수 있으면 좋겠다.

출처 : 유데미

Java 프로그래밍 강의

제품의 테스트 과정이나, 혹은 개발 그중에서도 특히 백엔드 개발의 경우 '모든 것이 완벽하게 돌아간다’라고 낙관적으로 생각하는 것은 매우 위험하다. 내가 생각하기엔 예외를 다양하게 검증해서 문제가 없다고 생각했던 API도 내가 생각하지 못했던 조건에서는 폭발 혹은 제대로된 값을 반환해 낼 수 있다…💥
(프론트엔드 개발자는 항상 내가 생각했던대로 요청을 보내오는 것이 아니고, 사용자는 항상 정해진 요청만 보내오는것이 아니다. 백엔드 개발자로서 항상 서비스의 안정적 운영이라는 사명을 가지고, 프론트엔드 개발자조차 생각하지 못했던, 혹은 중간에 모종의 과정으로 인해서 약속했던 값이 오지 않더라도 예외를 적절히 처리 할 수 있는 보다 안정성 있는 API를 구현하고자 노력하자…! 👊👊)

이러한 개발이나 유닛 케스트 과정에서 오류가 발생하는 경우를 엣지케이스와 코너케이스라고 부른다고 한다. 그렇다면 이러한 케이스들은 어떤 특징을 가지고 있으면서, 동시에 어떤 차이를 가지고 있는지, 마지막으로 각각에 대한 테스트가 필요한 이유가 뭘지 생각해보는 시간을 가져보자.

커먼 케이스(Common case)

시스템이나 애플리케이션에서 흔하게 발생하는 일반적인 상황을 나타냄.

• 일반적인 흐름을 테스트해서 시스템이나 서비스가 예상대로 동작하는지 확인하면 된다.
• 이러한 커먼케이스와 달리 문제가 되는 부분을 처리하는것이 ‘에러 헨들링’ '예외처리’를 다루는 테스트 케이스에서 다루어진다.

엣지 케이스(Edge case)

입력값이 최대 또는 최소값에 도달하는 경우 등 경계 조건에서 발생하는 특수한 상황을 나타냄.
즉, 초소/최대값 등 알고리즘이 처리하는 데이터 값이 알고리즘 특성에 따른 일정 범위를 넘은 경우 발생하는 문제

• 입력 값이 특정 범위의 최대 또는 최소값에 도달할 때 어떻게 동작하는지를 테스트 한다.
• 이러한 케이스는 단일 요소(데이터)로 인한 문제로, 디버그가 쉽기도 하고 테스트를 통해 미리 방지하기도 쉽다.

코너 케이스(Coner case)

정상적인 작동 매개변수를 벗어나서 외부 변수나 요인에 의해 발생하는 문제 혹은 상황을 의미.
즉, 사용하던 본래 잘 동작하던 서비스가 프레임 워크업데이트 후 비정상적 동작을 한다거나,A기기에서는 동작하는 서비스가 B 기기에서는 동작하지 않는 등 여러가지 요인과 환경에 의해 발생하는 케이스이다.

• 이러한 문제는 발견,예측하거나 테스트하기 어렵다.

결론

내가 보통의 경우에 작성해왔던 테스트 케이스들은 'Common case’와 ‘Error handling’ 'Exception 처리’에 대한 작성이었다는 것에 대해서 알게되었으며, Conercase에 대한 테스트까지는 어렵더라도 Edge case까지는 커버 할 수 있는 테스트코드를 작성하는 습관을 들여야겠다는 생각을 했다.

내가 기대했던 "보다 안정적인 서비스 개발을 위한 테스트 케이스 설계"에는 이렇다 할 만큼 큰 도움이 되지는 않았지만, 해당 용어들 관련해서 국내 기업들의 아티클을 검색하면서 우아한 형제들 - 서버 사이드 테스트 파랑새를 찾아서와, 카카오 페이 - 실무에서 적용하는 테스트 코드 작성 방법과 노하우 Part 1: 효율적인 Mock Test처럼 테크 기업들의 테스트에 대한 고민과 경험이 담긴 글을 찾아 읽게되었다. 결과적으로는 원했던 방향인 “보다 안정성 있는 서비스에 대해 고민하는 개발자” 조금은 가까워졌다고 생각 할 수있을 것 같다…!

참고자료

• wiki - 엣지 케이스
• wiki - 코너 케이스
• stackoverflow - What is the difference between an edge case and a corner case?

추후 학습 방향

• 우아한 형제들 - 서버 사이드 테스트 파랑새를 찾아서
• 카카오 페이 - 실무에서 적용하는 테스트 코드 작성 방법과 노하우 Part 1: 효율적인 Mock Test

위의 두 글에서도 느껴지듯, 대부분의 서비스들은 데이터의 정합성에 대해서 항상 고민하면서, 다양한 테스트 케이스를 커버 할 수 있는 테스트 코드를 짜고자 노력하는 것 같다. 하지만 테스트코드가 중요하다고 해서 Mock을 남발하는 테스트를 진행하거나, 좋은 테스트 코드에 대한 고민 없이 마구 작성된 테스트 코드는 개발의 효율성도 비즈니스의 속도도 늦추기 마련이라고 한다.

실제로, 기존에 Test코드를 기반으로 API 명세를 만들던 팀 프로젝트에서 Test의 coverage와, 유닛테스트를 중점으로 진행해야하는지 통합테스트를 중점으로 진행해야하는지 논의 없이 개발을 시작했던 적이 있었다. 코드리뷰 과정에서 서로의 테스트 코드에 공감을 하지 못해 혼선이 일었고, 뒤늦게 논의를 통해 "중심이 되는 테스트"와 "불가능 할 시 진행할 테스트 방법"에 대해 결정하고, test의 coverage를 어느정도까지 설정할 것인지 협의하느라 고생했던 적이 있었다.

위와 같은 기업들의 아티클을 통해 효율적인 테스트와, 효율적인 테스트 환경에 대해서 공부하고 고민해보면 좋을 것 같다.