Goal

• 테스트 케이스란?
• 테스트 케이스 종류
• 테스트 케이스를 작성해야 하는 이유

테스트 케이스란?

• 명세 기반 테스트의 설계 산출물로 설계된 입력값, 실행조건, 기대 결과로 구성되어 있는 테스트 항목의 명세서를 의미한다.

테스트 케이스 종류

종류	정의
기능 테스트	요구하는 목적을 만족하는지를 검증하는 테스트
도메인 테스트	경계값 분석등 관계성을 지닌 복수의 변수를 동시에 검증하는 테스트
사양기반 테스트	설계서 및 메뉴얼과 같은 문서 상에 기술된 내용과 소프트웨어가 똑같은 지능을 가진지 검증하는 테스트
부하 테스트	최대 설계 부하와 그 이상의 부하를 검증하는 테스트
회귀 테스트	프로그램이 변경 되었을 때의 이상을 검증하는 테스트
사용자 테스트	사용자에게 실제로 사용하도록 하여 결함 및 사용성을 검증 하는 테스트
시나리오 테스트	예상되는 일반적인 사용법을 검증하는 테스트
상태전이 테스트	설정의 전이가 올바르게 변화하는지를 검증하는 테스트
탐색전 테스트	사전에 작성한 테스트 케이스를 따르지 않고 결과를 검증하는 테스트
랜덤 테스트	임의적으로 입력하는 조작하는 테스트

테스트 케이스를 작성해야 하는 이유

휴먼에러

• 사람이라는 존재는 완벽한 존재가 아니기 때문에 항상 꼭 나도 모르게 실수를 하게 된다. 실수를 방지하기 위해 테스트 케이스를 잘 작성해 놓는 다면 실수를 방지 할 것이다. 또한 기존 코드의 변화가 있을때 마다 일일이 기능을 눌러서 검증하기 보다는 자동화된 테스트 코드로 검증한다면 쉽게 오류를 찾거나 검증 할 수 있다.

유연한 기능추가

• 기능을 추가할때 마다 다른코드에 영향을 끼치는지 파악을 해야한다. 만약에 자동화된 테스트가 없다면 수동으로 일일이 눌러서 오류를 찾아야 한다. 하지만 자동화된 테스트가 구축되어 있다면 쉽게 오류를 찾거나 검증 할 수 있다.

개발자용 문서화

• 지속적으로 빠르게 변하는 요구사항에 대해서 문서를 따로 작성하면 좋치만 관리하기도 힘들고 따로 시간을 들여야 하지만 비지니스 요구사항을 테스트 케이스로 작성한다면 새로참여하는 개발자가 와서도 빠르게 업무를 이해하는데 도움이 됩니다.

CI/CD를 통한 프로세서 자동화

• Jenkins를 통하여 거의 모든 프로세스가 자동화로 움직입니다. 이런 환경에서 개발자가 테스트 케이스를 작성하지 않고 배포가 된다면 휴먼에러가 언제 어떻게 터질지 모르는 폭탄을 배포하는 것과 같다.
• 배포할때마다 일일이 눌러보고 기능 테스트를 할 수 있는 자신이 있다면 ㅎㅎ 테스트를 작성안해도 될 것 같다.

코드 리팩토링

• 단위 테스트를 잘 작성하려고 노력하다 보면 해당 클래스가 역할에 맞게 설계가 되었나, 해당 클래스가 너무 많은 책임을 가지고 있는가 등등 SOLID 객체 지향 설계중 SRP(Single responsibility principle)-단일 책임 원칙을 잘 따르고 있는가? 등등 많은 고민을 통해서 더 깔끔하게 코드를 작성하게 된다.