테스트의 종류

TDD라는 개발론이 있다. Test Driven Development 의 줄임말인데 우리말로는 테스트 주도 개발 이라고 한다.

절차를 밟아가며 차례차례 진행 후 제품을 모두 개발한 후에 테스트를 진행하는 기존 폭포수방식에서 벗어나 모듈, 함수별로 즉각즉각 테스트를 진행하며 개발을 하자는 것이다.

뼈대를 다 만든후 테스트를 진행하는 기존 폭포수 모델의 경우 에러 혹은 의도치 않은 값이 나올경우 디버깅을 하는것도 힘들뿐더러 비용도 많이 소모된다. 하지만 함수, 메서드 하나를 만드는 와중에도 테스트를 진행하기때문에 에러를 보다 빨리 발견할수있고 수정에 소모되는 비용도 줄어든다. 또한 그만큼 제품의 완성도도 올라가게된다.

TDD에서 직접적으로 제안하는건 일단 실패코드를 작성하는 것이다. 최종적으로 원하는 함수를 먼저 구현하려애쓰지말고 간단한 기본값들이 들어왔을때부터 시작하며 처음 실패코드를 작성한 후 '그 해당 값'에만 대하여 성공하게끔 수정하고 다시 다른 값으로 테스트를 하고 리팩토링하는 사이클을 유지함으로서 그 와중에 생기는 중복코드들은 계속 되는 리팩토링에서 제거하며 진행하는것이다.

위에서 TDD의 장점으로 에러를 빨리 발견하고 수정에 소모되는 비용이 줄어든다고했지만 계속 되는 리팩토링으로인해 코드의 품질 자체도 상승하게되는 장점이 있다.

하지만 처음 TDD에 충실하게 개발을 하려다보면 너무나도 당연한것조차 테스트를 진행 후 리팩토링을 거치기때문에 답답함을 느낄수도있으며(안그래도 우리나라사람들 성질급한데) 간단한 에러는 존재할 수 있을지언정 빠르게 결과를 보여야하는 프로토타입을 개발하기에는 비교적 적절하지않을 수도있다.

허나 그런 상황이 아니라면 TDD는 지금 당장은 느릿느릿하다고 보일수 있으나 결과적으로 더 높은 품질의 제품을 얻을 수 있으므로 좀 느릴지언정 확실하게 한걸음씩 내딛는 개발방법이라고 생각한다.

자바에는 Junit 이라는 라이브러리가 테스트를 도와주며 자바스크립트에는 QUnit이라는 라이브러리가 존재한다. '그냥 만들고 돌려보면 되지 뭐' 라고 생각할 수도 있는 테스트에도 선배개발자들이 정해놓은 종류가 존재하는데 그것만 확인하고 포스팅을 마치겠다.

수준별 테스트 분류

단위테스트

-가장 작은 단위. 메서드, 함수별로 테스트하는 것

통합테스트

-함수들이 모여서 모듈이 정상적으로 작동하는지 확인하는 테스트

시스템테스트

-제품 완성 후 배포까지 한 상태에서 진행하는 테스트

인수테스트

-고객의 요구사항을 충실히 구현했는지 고객이 직접 진행하는 테스트

목적별 테스트 분류

긍정테스트

-구현한대로 흘러가는지 원래 필요로하는 값을 입력한 후 진행하는 테스트

부정테스트

-원래 필요로 하는 값이 아닌 값을 넣어 진행하는 테스트

예.전화번호 필드에 문자열, 특수문자 등을 넣는 행위

새너티 테스트

-정상적으로 흐름이 진행되는지 빠르게 하는 테스트

회귀 테스트

-A 함수에 수정사항이 생겼을경우 A에 의존하고있는 B가 정상적으로 진행되는지 확인하는 테스트

부하 테스트

-시스템이 견디는 범위를 넘어서는 요청을 보내 어떤 증상을 보이는지 확인하는 테스트

로드 테스트

-시스템이 어디까지 견딜 수 있는지 범위를 확인하는 테스트

기법별 테스트 분류

화이트박스 테스트

-소스에 대해 아는 사람이 진행하는 테스트. 문제가 생겼을때 빠르게 대응할 수 있지만 자신도 모르게 긍정테스트를 진행하는 경향이 있다.

블랙박스 테스트

-소스를 아예 모르는 사람이 진행하는 테스트. 돌발적인 값을 넣을 수도 있기에 개발자입장에서는 긴장이 되지않을까 한다.

그레이박스 테스트

-화이트와 블랙을 섞은게 그레이인데... 그말 그대로 소스를 어느정도만 알고있는사람이 진행하는 테스트.