Test
소프트웨어가 가진 결함을 밝히는 과정
설계와 다르게 동작한다면 모두 소프트웨어의 결함이다!
이미 제작된 소프트웨어에 대해서 테스트 케이스를 만들고, 테스팅하는 것은 시간과 노력이 많이 들어가므로
요즘에 개발 초기부터 테스트케이스를 만들고 이것을 개발하는 TDD(Test-driven development) 방식이 각광받고 있다.
Test 종류
E2E test (UI test)
사용자 관점에서 테스트 하는 것
어떤 어플리케이션이 제대로 동작하는지
완전한 기능을 테스트 하는 것이다.
예를들어 회원가입 로그인 기능을 개발 했을 때, 사용자라 가정하고, 로그인 회원가입을 직접 해보는 것이다.
수동으로 일일이 해 볼 수 있으므로
실행이 쉽다는 장점이 있지만 시간이 오래 걸리고
자동화 하기 까다롭다는 단점이 있다.
Integration Test
모듈을 통합할 때, 모듈 간의 호환성을 테스트 하는 것
여러 개의 모듈들이 통합되면서 모듈들 끼리 상호작용하며 기능을 수행한다
그렇기에 통합된 모듈들이 올바르게 연계되어 동작하는지 검증이 필요한데, 이러한 목적으로 진행되는 테스트가 통합 테스트다
Unit Test
독립적으로 진행되는 가장 작은 단위를 테스트 모듈에서 일반적으로 하나의 기능을 수행하는 함수나 메소드를 테스트 하는 것이다
일반적으로 테스트 코드를 작성한다고 하면 거의 단위 테스트를 의미 한다. 단위 테스트는 독립적으로 테스트 하기 때문에 리팩토링하여도 빠르게 문제 여부를 확인 할 수 있다.
단위 테스트의 장점
- 테스팅에 드는 시간과 비용을 절감 할 수 있다
- 새로운 기능 추가 시 수시로 빠르게 테스트 할 수 있다
- 리팩토링 시 안정성을 확보할 수 있다
- 코드가 바뀌었을 때, 변경한 부분으로 인해 발생하는 현상을 쉽게 파악 할 수 있다.
단위 테스트의 작성시 유의 사항
- 1개의 테스트 함수는 1가지 기능만을 테스트하라
- 테스트 함수의 이름은 어떤 기능을 테스트하는지 최대한 자세하게 작성
- 1개의 테스트 함수에 대해 assert를 최소화
FIRST 규칙
FAST : 테스트는 가능한 빠르게 동작하도록 하여 자주 돌릴 수 있어야 한다.
Independent : 각각의 테스트는 서로 독립적이어야 한다
Repeatable : 환경에 관계 없이 반복 가능해야 한다.
Self - Validating : 테스트 결과는 성공 혹은 실패로 자체적으로 검증되어야 한다
Timely : 테스트 하려는 실제 코드를 구현하기 직전에 구현 해야 한다.
