[Project design] 프로그램 검증과 테스트 - Unit 테스트

안녕하세요. 명월입니다.

이 글은 프로그램 검증과 테스트 - Unit 테스트에 대한 글입니다.

프로그램 테스트라는 것은 프로그램 설계와 작성만큼이나 매우 중요한 작업입니다. 보통 신입 개발자분 들이나 프로그램을 처음 공부하시는 분들이 정말 쉽게 생각하고 테스트 자체를 큰 비중을 두지 않는 면이 많습니다. 적어도 저는 그랬던 거 같습니다.

테스트라는 것은 프로그램을 상품이라고 했을 때, 상품의 품질과 관련이 있는 부분이고, 서비스가 진행되었을 때는 서비스에 대한 신뢰도에 대한 문제이기 때문에 어떻게 보면 설계와 작성보다도 더 중요한 작업이 이 테스트인 듯싶습니다.

저는 일본에서 근무한 경력이 많습니다만, 일본에서의 프로그램 공정이 오히려 이 테스트를 더 많이 신경쓰고 프로젝트 관리자의 중에서도 품질 관리자(테스트 관리자)가 프로젝트내에서 엄청난 파워를 가지고 있습니다. 아마 개인적인 생각입니다만 일본은 자신들의 메이드인 제팬이라는 자부심이 있어서인지 이런 품질과 안정성을 어마어마하게 따지는 경향이 있습니다.

테스트를 함에 있어서 프로그램이라는 것은 기본적으로 사람이 설계하고 코딩을 하는 작업이 많이 있기 때문에 기본적으로 실수가 반드시 발생한다는 전제로 시작합니다.

태스트의 단계는 크게 3단계로 단위 테스트(UT: Unit test), 결합 테스트(IT: Integration test), 시나리오 혹은 스텐다드 테스트(ST: Standard test or System test)로 나뉘어 집니다.

그리고 테스트의 설정 범위는 단위 테스트는 코딩을, 결합 테스트는 상세 설계, 시나리오 혹은 스텐다드 테스트는 기본 설계를 테스트하는 범위로 설정됩니다.

위 공정은 워터폴 공정의 설계부터 개발 그리고 테스트의 기본 구조입니다.

프로그램 테스트 설계와 실행도 역시 사람이 하는 일이기 때문에 이 과정에서도 실수가 발생할 수 있습니다. 즉, 최악의 시나리오가 설계에서 실수하고 코딩에서 놓치고 마지막으로 테스트에서도 확인을 못하게 된다면 그 프로그램은 버그가 발생하는 것입니다.

테스트라는 것은 어찌보면 프로그램 납품 전의 최종 확인과 같은 것이기 때문에 테스트부터는 최소 2명이 하나의 팀이 되어 크로스 체크(Cross check)가 기본 형태입니다.

설계 혹은 테스트한 사람이 설계도를 작성합니다. 그리고 테스트의 시행과 테스트 결과 확인에 대해서는 다른 사람이 하는 것입니다. 내가 설계 코딩하고 테스트까지 하면 자기만의 논리와 생각에 빠져 버그를 발견하기 힘들기 때문입니다.

솔직히 이렇게 해도 버그가 발생하는 경우가 많이 있습니다만, 그나마 제조 단계에서 발생하는 버그를 최소한으로 줄일 수 있지 않을까 생각됩니다.

저도 프로젝트를 운영할 때, 워터폴 공정을 좋아하진 않습니다. 일단 시간이 너무 많이 걸린다는 단점이 있습니다. 문서도 많아지고...

그래서 제조까지는 빠르게 애자일 형식으로 넘어갑니다만 테스트부터는 애자일의 검증 프로그램등을 이용한 버그 체크를 좋아하지 않습니다.

이유는 프로그램을 만들고 프로그램을 검증하는 프로그램을 만들었습니다. 이유는 역시 빠른 공정을 위한 것이지요.. 그럼 이 검증 프로그램이나 스크립트는 누가 검증하나요?

많은 사람들에게서 애자일 공정으로 프로그램을 만들고 우리는 자체 검증 프로그램을 만들어서 버그가 발생하는 확율이 확실히 적고 빠른 개발이 가능하다고 하는데.. 이 검증 프로그램과 스크립트는 그럼 검증이 된 것인가하는 의문이 듭니다.

결국 이 프로그램도 사람이 만든 것이라 반드시 버그가 일어날 수 있는 것인데 말입니다. 물론 안하는 것보다는 훨씬 좋겠지만 그래도 그게 반드시 버그를 낮추는 데 좋다라는 것은 이해가 되지 않네요.

그렇다고 저는 이런 툴을 전혀 안 쓰는 것은 아닙니다. 테스트는 워터폴처럼 UT, IT, ST를 나누어서 작업합니다만, UT의 경우는 Java의 JUnit과 C#의 MSTest를 이용하고 IT는 웹 개발의 경우는 Python을 통한 selenium을 이용하고 ST는 어쩔 수 없이 사람이 최종 확인하는 방식으로 테스트를 진행합니다.

먼저 여기서는 단위 테스트에 대해서 설명하겠습니다.

저는 웹 개발의 경력이 많으니 웹 개발 프로젝트의 경험 위주로 설명하겠습니다.

웹에서는 우리가 최근에는 Java의 경우는 Spring을 쓰고 C#에서는 MVC를 사용합니다.

여기서 단위 테스트에서 검증을 해야 할 것들은 클래스와 함수들입니다.

View의 html를 단위 테스트에서 검증하기에는 조금 힘이 드는 부분이 있네요. 그렇다고 안되는 건 아닙니다만 태그와 css와 스크립트를 다 검증하기에는 unit 테스트의 범위가 너무 넓어집니다. 그리고 저는 보통 화면을 기본 설계와 상세 설계 단계에서 만들어 버리기 때문에 Unit 테스트보다는 IT와 ST로 넘겨버립니다.

그리고 단위 테스트에서 체크하기 힘든 부분은 Controller 함수입니다. 즉, 웹에서 요청이 왔을 때, 프레임 워크에 따라 호출되는 함수들입니다. 보통 이 함수에는 웹 데이터의 Request 정보와 Session, Cookie 정보들이 있는 데, 이 정보들을 역시 다 만들기에는 어려움이 있습니다. 그리고 이런 테스트에 필요한 데이터가 많아질 수록, 실수를 발생할 확율이 높아집니다.

그래서 단위 테스트에서는 함수와 클래스입니다.

일전에 코딩을 할 때 함수를 만드는 방법에 대해서 설명한 적이 있습니다.

링크 - [Project design] 프로그램 생산과 작성(코딩) - 함수 작성법

그렇습니다. 제가 설명한 방법대로 함수를 작성하셨다면 반드시 Input, Output에 대한 정의가 명확할 것입니다. 즉, 이 함수들만 생각하고 가능한 Input 데이터와 Output 데이터를 생각하고 최대한 많이 넣고 결과를 확인하는 것입니다.

여기서 작업은 Unit 테스트의 프로그램은 내가 작성하고 데이터의 대한 정의는 다른 사람이 하는 것으로 해서 생각의 오류에 대한 버그를 최소화하는 것이 좋습니다.

클래스를 작성하는 방법에 대해서도 설명한 적이 있습니다.

링크 - [Project design] 프로그램 생산과 작성(코딩) - 클래스 작성법

여기서는 디자인 패턴대로 싱글톤이라고 하면 인스턴스가 중복 선언이 되는지 확인등의 디자인 패턴 상의 클래스 체크와 내부 변수를 Reflection으로 취득해와서 디버깅 표를 만들어 데이터 흐름이 사양대로 흘러가는 지 확인합니다.

이렇게 하면 따로 문서로 테스트 설계도를 작성할 필요없이 프로그램으로 모든 걸 해결할 수 있습니다.

그럼 이 단위 테스트를 언제하는 것이 좋은가 입니다.

역시 프로그램 제조가 모두 끝난 상태에서 하는 것이 좋습니다만, 또 그러기에는 우리가 다른 팀의 작업이 끝날 때까지 마냥 놀 수는 없습니다.

저는 이 단위 테스트를 3번 정도 실시 하는데 먼저 저장소에 Commit 할 때 입니다.

예전에 SVN 쓸 때는 이걸 위해 또 따로 스크립트 만들고 귀찮았는데 요즘에는 Jenkins + Gihub 쓰면 자동으로 체크해 주는 기능이 있더군요...

다른 팀의 모든 작업이 끝나고 최종 결합(merge)할 때, 전체적으로 또 이 단위 테스트를 돌립니다. 그리고 결합 테스트를 위해 Dev 환경(개발 서버)에 Deploy(배포)할 때 또 이 단위 테스트를 돌립니다.

이게 글로 쓰니 굉장히 귀찮을 정도로 많이 한다라고 생각합니다만, 사실 이게 CI툴로 인해 모든게 자동으로 이루어집니다.

나는 프로그램 제조하고 테스트 클래스를 만들어서 Commit을 PR(Pull request)를 합니다. CI툴에서 자동으로 검증을 해줘요.. 검증이 OK되면 관리자가 merge를 하겠지요.. 그럼 또 CI툴에서 자동으로 검증을 합니다.

스크럼에 의해 CI 툴이 정해진 시간에 Dev 환경(개발 서버)에 자동으로 Deploy를 하는데 또 그때 자동으로 검증을 합니다. 물론 검증 중에 에러가 발생하면 Failed로 스크럼은 멈추게 되고 담당자에게 메일이 전송이 됩니다.

단위 테스트는 보통 이런 식으로 흘러가지 않나 싶습니다. 이게 개인적인 경험이고 제가 지금도 현업에서 자주 운영하는 방식입니다. 꼭 정답은 아니니 참고만 해주세요.

여기까지 프로그램 검증과 테스트 - Unit 테스트에 대한 글이었습니다.

궁금한 점이나 잘못된 점이 있으면 댓글 부탁드립니다.