여기 기능을 가진 Production code가 있다.
Production code는 계속해서 요구사항을 반영해서 기능을 확장해 나간다.
만약 Production code를 사람이 계속 테스트 한다면?
- Production code 확장하는 만큼, 기존의 코드도 또 테스트 하게 되며, 커버 할 수 없는 영역 발생 하게된다.
- 코드가 확장됨에 따라, 경험과 감에 의존하게 된다.
- 시간이 오래걸리니 늦은 피드백을 받게 된다.
- 유지보수가 어려워진다.
결국 소프트웨어의 신뢰도가 하락하게 된다.
테스트 코드를 작성하지 않는다면?
- 변화가 생기는 매 순간마다 발생할 수 있는 모든 case를 고려해야 한다.
- 변화가 생기는 매 순간마다 모든 팀원이 동일한 고민을 해야한다.
- 빠르게 변화하는 소프트웨어 안정성을 보장할 수 없다.
아무렇게나 TestCode를 짜면 될까?
테스트 코드가 엉망으로 작성되었다면?
- Production code 의 안정성을 제공하기 힘들어진다.
- 테스트 코드 자체가 유지보수하기 어려운, 새로운 짐이된다.
- 잘못된 검증이 이루어질 가능성이 생긴다.
올바른 테스트 코드를 작성한다면?
- 자동화 테스트로 비교적 빠른 시간 안에 버그를 발견할 수 있고, 수동 테스트에 드는 비용을 크게 절약할 수 있다.
- 소프트웨어의 빠른 변화를 지원한다.
- 팀원들의 집단 지성을 팀 차원의 이익으로 승격시킨다.
'TDD' 카테고리의 다른 글
Presentation Layer의 테스트 (0) | 2024.11.24 |
---|---|
레이어드 아키텍처(Layered Architecture) 와 테스트 (0) | 2024.11.18 |
테스트는 [문서]다 (1) | 2024.11.15 |
TDD가 정확히 무엇일까? (0) | 2024.11.11 |
단위테스트(Unit test) (1) | 2024.11.10 |