unit test는 왜 필요할까 ?
개발을 하고 나서 해당 소스 코드가 제대로 작동이 되는가를 확인해야 한다. 제대로 작동이 되지 않는 코드는 그 자체로 의미가 없다. 기능 개발에만 몰두한 채 소스코드 테스트를 하지 않으면 결국 유저(고객)의 몫이 되어버린다.
내가 테스트를 해서 문제를 발견하여 고치면 그만이지만 유저가 발견하고 그 문제를 겪게 되어버리면 금전적 손실, 신뢰도에 문제가 생길 수 있기에 테스트 과정은 새로운 기능 개발 만큼이나 중요하다.
software system 테스트의 3가지 방법
1. UI Testing / End-To-End Testing
-
UI Testing은 자동화 하기가 어렵고 까다롭고 또한 실행도 까다롭다.
-
Manual Testing은 실행하기 쉽지만 비용이 많이 들고 직접적인 인력이 들어가며 실행이 오래 걸리고 부정확 하다. 이렇게 하다가 나중에 새롭게 구현한 기능만 테스트 하게 된다면 다른 기능에서 문제가 생기는 사태가 벌어질 수 있다.(다른 기능을 껴서 새 기능을 테스트 하지 않았기 때문에)
-
요즘은 어느정도 이런 유형에 대한 테스트도 자동화 된 편
2. Integration Testing
- 내가 담당한 시스템만 작동시켜 테스트 하는 것(FE는 FE만 BE는 BE만)
- UI Test/E2E Test 다음으로 비용과 노력이 많이든다.
3. Unit Testing
- 코드에서 테스트 할 수 있는 가장 작은 단위 -> 함수, 메소드
- 즉 테스트 하는 코드를 짜서 작성한 코드를 테스트 한다.
- 왜 비용이 저렴할까 ? -> 사람이 실행하는 것이 아닌 자동화(시스템이 직접)가 가능하기 때문이다.
- 단점 : unit test를 구현해야 하는 부분에서 overhead가 걸릴 수도 있다. 구현보다 테스트에 시간이 더 걸릴 수도 있을 정도로…
- Unit test는 나의 방패다(나 자신을 보호해주는 최소한의 장치)
- test를 잘 짜두면 앞으로의 업무에서도 좀 더 수월할 수 있다.
- test를 덜한다고 해서 존재하는 bug가 없어지지 않는다. -> 결국 user의 몫이 된다.
- bug는 있을 수 밖에 없다고 생각해라.
- 구현과 테스트의 비율은 5:5의 비율로 한다 생각할 정도로 테스트를 중시해야…
- Unit test의 유형
- happy path unit test : 통과할 테스트 케이스만 테스트 한다.
- (좀 더 고차원) 아닌 결과물도 테스트 해본다
(ex) 로그인 테스트 : 맞는걸 넣는 것(1에 해당하는 케이스), 틀린 계정 정보를 넣는것(-1에 해당하는 케이스) - (좀 더 고차원) 예외의 경우(0의 경우)에도 테스트 해본다.(비어있는 값 넣기, 아주 큰 값을 넣어보기, 다른 자료형의 데이터를 넣어보기 등) -> 생각하기 어려운 테스트 케이스
- 최소한 1(명백히 맞는 경우)과 -1(명백히 틀린 경우)의 테스트를 해주어야 한다
- Unit test가 끝난 데이터들은 '삭제'해 주어야 한다.
- 이후 테스트에 의존성 영향을 끼쳐서는 안된다.
- 즉 각각의 테스트는 독립적으로 작동해야 한다.
- Unit test는 신속해야 하며 실제 라이브 서비스에 대해 요청을 보내서는 안된다.
wanna be good developer