코드리뷰와 테스트

코드리뷰의 목적?

성장을 목적으로 하는 코드리뷰! 함께 성장하기 위한 수단으로 리뷰를 활용하자.

 

버스팩터 (Bus Factor)

: 팀원이 버스에 치였을 때 프로젝트가 망할 가능성에 대한 지수

  이 지수는 프로젝트가 내포하고 있는 리스크를 의미하며,

  지수가 낮을 수록 프로젝트가 특정인에게 쏠려있고 정보공유가 원활하지 않다

 

코드리뷰의 부작용 

- 병목이 되는 코드리뷰

- 의미없는 코드리뷰

- 싸움이 되는 코드리뷰

- 책임 소재를 묻는 코드리뷰

성장을 목적으로 하는 것이 중요함

 

질문도 리뷰다

테스트 필수

Pre-commit Review : Github에 커밋되기 전 사전 리뷰 단계

 

 

 

테스트 

일곱 테스트 원칙

1. 테스팅은 결함의 존재를 보여주는 것2. 완벽한 테스는 불가능3. 테스트 구성은 가능한 빠른 시기에 시작4. 결함은 군집되어 있다5. 살충제 역설 - 비슷한 테스트가 발견되면 새로운 결함을 발견할 수 없다6. 테스팅은 정황에 의존적7. 오류 부재의 오해 - 사용되지 않는 시스템의 결함을 찾고 수정하는 것은 의미없다

 

F.I.R.S.T 단위 테스트 원칙

Fast 유닛 테스트는 빨라야 한다

Isolate 다른 테스트에 종속적인 테스트 작성은 X

Repeatable 테스트는 실행할 때마다 같은 결과를 만들어야 한다

Self-validating 스스로 결과물의 옳고 그름을 판단할 수 있어야 한다

Timely 유닛 테스트는 프로덕션 코드가 테스트를 성공하기 직전에 구성되어야 한다

 

 

테스트 피라미드

 

 

Unit Test (단위 테스트)

- 소형 테스트에 속하는 테스트

- 클래스 범주 내 작은 단위(함수) 기능에 대한 유효성 검증 테스트

 

Integration Test (통합 테스트)

- 중형 테스트에 속함

- 서로 다른 모듈 혹은 클래스 간 상호작용의 유효성을 검사하는 테스트

 

UI Test

- 대형 테스트에 속함

- 실제 사용자들이 사용하는 화면에 대한 테스트를 하여 서비스의 기능이 정상적으로 작동하는지 검증

 

 

 

TDD (테스트 주도 개발)

Test-driven development: 개발 전 테스트 코드를 먼저 작성

 

테스트를 먼저 짜고, 테스트를 통과할 만큼의 코드만 짜서 테스트

실패하는 테스트를 먼저 작성하고 그에 해당하는 기능을 만들어감

이후 리팩토링으로 효율성 향상시키기

 

• Red 단계에서는 실패하는 테스트 코드를 먼저 작성
• Green 단계에서는 테스트 코드를 성공시키기 위한 실제 코드를 작성
• Blue 단계에서는 중복 코드 제거, 일반화 등의 리팩토링을 수행

 

TDD 개발 방식