TDD
- Test Driven Developer = 테스트주도개발
- 테스트 코드를 먼저 작성하고, 테스트를 통과하기 위한 것을 짜는 것
추상적인 레벨에서의 TDD의 핵심개념
- 결정과 피드백 사이의 갭에 대한 인식
- 결정 : 프로그래밍을 하다보면 '이 방법으로 해야지','이렇게 짜야지'라는 결정을 한다
- 피드백 : 프로그래밍시에 받는 성공/실패(에러)
- 불확실성이 높을 때 '피드백'과 '협력이 중요하다 -> TDD도 피드백과 협력을 증진시키는 것
TDD가 필요한 상황
- 처음해보는 프로그램 주제 -> 나에 대한 불확실성
- 고객의 요구조건이 바뀔 수 있는 프로젝트 -> 외부적인 불확실성
- 개발하는 중에 코드를 많이 바꿔야한다고 생각하는 경우
- 내가 개발한 후 이 코드를 누가 유지보수할지 모르는 경우
TDD의 장단점
- 결함이 줄어든다
- 코드 복잡도가 떨어진다 = 깨끗한 코드, 유지보수 비용이 낮아진다
- 개발시간이 늘어난다
단위테스트 Unit Test
- 특정 모듈이 의도된 대로 정확히 작동하는지 검증하는 절차
- 모든 함수와 메소드에 대한 테스트 케이스를 작성하는 절차
- 개발자가 수행하고 자신이 개발한 코드 단위(모듈, 구성요소)를 테스트한다
- 개발 라이프 사이클의 초기 단계에서 버그가 식별되므로 버그 수정 비용을 줄이는 데 도움이 된다
단위테스트의 필요성
- 프로그램이 크고, 메모리가 많이 들고, 다른 리소스가 필요한 경우 로컬 환경에서 쉽게 코드를 실행시켜보기 어렵다. 따라서 이런 프로그램을 개발하는 개발자들은 유닛테스트를 만들어서 빠르게 자시의 코드가 정상적으로 작동하는지 확인할 수 있다
- 종석성이 있는 다른 클래스들에서 버그가 나는 것을 방지한다
Unit 테스트의 조건
- 독립적되어야한다. 어떤 테스트도 다른 테스트에 의존하면 안됨
- 격리되어야 한다. ajax, axios, localStorage등 테스트 대상이 의존하는 것을 다른 것으로 대체해야 한다
통합테스트
- 모듈들의 상호 작용이 잘 이루어지는지 검증하기 위해서
- 통합하는 과정에서 발생할 수 있는 오류를 찾기위해서
📑 reference
한약은 거들뿐