Unit, Integration and End-To-End Test

 

 

 

테스트의 종류

Unit Test

테스트할 수 있는 가장 작은 단위(함수)로 기능을 쪼개서 테스트하는 방식

만약 문제가 일어난다면 어디서 일어나는지 가장 효과적으로 알 수 있다.

가장 좋은 방식이라 생각되는 테스트

 

도구) jest, mocha 등 사용

 

보통 jest의 경우는 프론트는 프론트만, 백엔드는 백엔드의 기능만 테스트하고 다른 부분은 mocking해서 

정상적으로 동작한다고 가정하고 해당 'Unit'만 테스트하는 방식이다.

 

-> 기능 테스트 위주로 하는거 추천?

 

Intergration Test

 

말 그대로 코드들을 '통합' 해서 문제가 없는지 확인하는 테스트

보통은 협업할때 내 코드와 팀원의 코드가 결합되도 문제가 없는지 확인하는 테스트이다.

커뮤니케이션적인 측면이 많이 필요한 테스트라 생각이 든다

 

도구) jest, cypress 등 사용

 

E2E(End-To-End) test

유저의 입장에서 내가 만든 프로그램이 의도대로 제대로 작동하는지 확인하는 테스트 

front, backend 전부 하나로 묶어서 테스트하고 실제 배포전에 문제를 발견하기 가장 쉬운 방법이지만

'어디서' 문제가 발견되는지는 까다로울 수 있다. (front인지 backend인지, 기능 여러개를 묶었다면 어디서 오류가 발생된건지 E2E test만으로는 발견하기 어려울 수 있음)

 

따라서 E2E test 만 하는것보다는 Unit test와 병행해서 하는것을 추천한다.

 

도구) 셀레니움, cypress 등 사용

 

-> UI 테스트는 E2E로 하는거 추천?

 

좋은 테스트의 비율?

 

구글 컨퍼런스에 따르면, 

Google often suggests a 70/20/10 split: 70% unit tests, 20% integration tests, and 10% end-to-end tests. 

라고 한다.

 

그외 팁으로는 

• 기존의 레거시 코드는 E2E 테스트로 커버하라.
• 새로 개발하거나 변경하는 부분을 대상으로 우선적으로 단위 테스트를 시작하라.

E2E 테스트 또한 기능이 복잡하거나 중요한 기능부터 커버하기 시작하면 효율적으로 단위테스트 적용이 가능할 것이다.

 

TEST의 장점

- 리펙토링시 test가 안정성을 담보하므로 거침없이 리펙토링을 할 수 있다.

- 코드 변경으로 어떤 부분이 영향이 있는지 빨리 파악 가능하다

- 테스트 자동화시(CI) 실수를 빨리 캐치하고 커뮤니케이션 비용을 줄일 수 있다.

- 버그 수정에 드는 시간을 줄일 수 있다

- test를 짜는데 초반엔 시간이 많이 들어도 장기적으로 보면 시간을 절약할 수 있다.

TEST의 단점

살충제 패러독스 

 

동일한 테스트 케이스를 사용하여 반복적으로 테스트를 수행하면 새로운 버그를 찾지 못한다.

소프트웨어는 복잡계이고, 테스트를 다 통과했다고 완벽한 소프트웨어는 아니다.

내가 예상치 못한 부분에 버그가 숨겨져 있을 수 있다.

 

- 러닝 커브

- 팀이 테스트에 대해 미적지근한 반응이라면 이도저도 안될수도 있음

 

같이 보면 좋을 동영상)

 

https://www.youtube.com/watch?v=jdlBu2vFv58 

 

reference 

 

https://codeahoy.com/2016/07/05/unit-integration-and-end-to-end-tests-finding-the-right-balance/

Unit, Integration and End-To-End Tests - Finding the Right Balance

 

https://www.popit.kr/unit-test-%EB%8B%A8%EC%9C%84-%ED%85%8C%EC%8A%A4%ED%8A%B8-%EB%8F%84%EC%9E%85%ED%95%98%EA%B8%B0-1%ED%8E%B8/

Unit Test (단위 테스트) 도입하기 - 1편 | Popit