TDD(Test-Driven Development)
TDD(Test-Driven Development)
- 선 개발 후 테스트 방식이 아닌,
선 테스트 후 개발 방식의 프로그래밍 방법
TDD 개발주기
- Red 단계 -> 실패하는 테스트 코드를 먼저 작성
- Green 단계 -> 테스트 코드를 성공시키기 위한 실제 코드를 작성
- Blue 단계 -> 중복 코드 제거, 일반화 등의 리팩토링을 수행
TDD의 장점은 무엇인가?
- 빠른 피드백
- 개발자가 작성한 코드가 바로바로 테스트되기 때문에 빠른 피드백을 받아 코드의 품질을 높일 수 있음
- 코드에 대한 디버깅과 유지보수가 압도적으로 쉬워짐
- 코드 품질 향상
- 테스트 케이스를 작성하기 때문에, 개발자는 불필요한 코드 작성을 방지하고 품질을 높일 수 있음
- 문서화
- 테스트 코드를 작성하는 과정에서 히스토리가 남기 때문에, 개발자와 고객 간뿐만 아니라 협업에 있어서 의사소통을 원활하게 할 수 있음
TDD의 단점은 무엇인가?
- 생산성의 저하
-> 단기적으로 봤을때, 테스트 코드를 작성하는 시간이 소모
- 비용 추가
-> 테스트 코드 작성하는 것 자체에 대한 비용이 커질 수 있음
어떤 경우에 TDD를 쓰기 적합한가?
- 고객의 요구조건이 바뀔 수 있는 프로젝트
-> 외부적인 불확실성이 높은 경우
(중간중간 코드를 많이 바꿔야 된다고 생각하는 경우)
- 개발하고 나서 이 코드를 누가 유지보수할지 모르는 경우
리액트에서 대표적으로 쓰이는 JEST, ZEST
- JEST
- 주로 리액트 애플리케이션의 단위 테스트를 위한 도구
-> 리액트에서는 컴포넌트 기반으로 개발하기 때문에,
컴포넌트의 단위 테스트를 위한 Jest의 기능은 매우 좋음
1. 유닛 테스트(Unit Test)
-> 각각의 함수 또는 모듈이 제대로 동작하는지 확인
2. 통합 테스트(Integration Test)
-> 다수의 모듈이 함께 동작할 때 제대로 동작하는지 확인
3. 스냅샷 테스트(Snapshot Test)
-> 컴포넌트 렌더링 결과물이 이전과 같은지 확인
4. 비동기 테스트(Async Test)
-> 비동기 코드가 제대로 동작하는지 확인
- ZEST
- 주로 애플리케이션의 보안 테스트를 위한 도구
-> 보안적 취약점을 검사하는 데 사용