테스트 코드가 필요한 이유
먼저 Production code를 작성하게 된다
처음에는 테스트를 한다 잘 동작하는걸 체크한다 그런데 점점 더 커지게된다면?
- 커버할 수 없는 영역 발생
- 경험과 감에 의존
- 늦은 피드백
- 유지보수 어려움
- 소프트웨어 신뢰성 낮아짐
제가 개발을 하면서 테스트코드 작성의 중요성에 대해 느낀부분은 바로 협업을 하면서였습니다.
제가 기능을 추가하면서 다른사람의 코드에 영향을 줄수도있는 부분이 생길때 잘 작동하는지 체크할때 어려움이 있었습니다. 따라서 이런 문제로 테스트코드를 작성의 필요성을 느끼게되었습니다.
테스트 코드 장점
- 빠른 피드백 : 내가 원하는대로 동작하는지 빠르게 피드백을 받을 수 있다
- 자동화 : 매번 사람이 모든케이스에 대해서 검증하면은 매우 비효율적이다 그래서 기계가 검증하면서 소프으웨어의 안정감을 높일 수 있다.
최종단계에서는 QA로 사람들이 다 테스트해보지만 매번 사람들을 QA하는것은 리소스 낭비이다. 따라서 테스트코드를 작성하면 이러한 리소스를 절약할 수 있다.
잘못된 테스트코드의 문제
테스트코드를 작성한다면 Production Code가 작성됨으로써 테스트코드도 같이 증가하게됩니다.
그러나, 잘못된 테스트코드를 작성하게 된다면 발생하는 문제점이 있습니다. 테스트코드가 굉장히 복잡하다 예를들어 무엇을 테스트하는지 모르는 문제가있다면은 오히려 다른팀원이 테스트코드를 봤을때 건드리고 싶지않게된다. 여러 부작용이 발생
즉 테스트 코드 작성하는것도 중요하지만 Production code를 명확히 지원할 수 있게 잘짜는게 중요하다
테스트 코드를 작성하지 않는다면
- 변화가 생기는 매순간 발생할 수 있는 모든 Case를 고려 해야한다 : 테스트코드를 작성하지 않으면 여러 케이스에 대해 영향을 미치는 경우를 직접 생각해야한다 그러나 테스트경우는 코드를 보고 여러 케이스에 대해 알수있으니 고려해야하는점을 코드로 알 수 있다
- 변화가 생기는 순간마다 모든 팀원이 동일한 고민을 해야 한다 : 같이 협업할때 기능B를 추가시에 기존 기능을 만들었던 부분에 영향을 미치는지 옆에 개발자도 고민해야한다. 서로 공유가 안되기때문에
- 빠르게 변화하는 소프트웨어의 안정성을 보장할 수 없다 : 코드가 정상작동하는지 직접 검증하는것만 방법이고 연동시에 문제가 생기는지 확인하는게 어려움 기능추가시에 시간이 너무오래걸림 검증을 직접해야하는것도 존재하기때문에
테스트코드가 병목(잘못작성)이 된다면
- 프로덕션 코드의 안정성을 제공하기 힘들어 진다.
- 테스트코드 자체가 유지보수하기 어려운, 새로운 짐이 된다
- 잘못된 검증이 이루어질 가능성이 생긴다
올바른 테스트 코드
-
자동화 테스트로 비교적 빠른 시간에 버그 발견과 수동테스트에 드는 비용을 크게 절약 : 수동이란 직접 요청해서 눈으로 확인하는거 콘솔이나 포스트맨으로 요청하는 경우
-
소프트웨어의 빠른 변화 지원
-
팀원들의 집단 지성을 팀 차원의 이익으로 승격 : 코드로 녹여내면 다른사람도 보면서 A라는 기능에는 이런 케이스가 있구나 팀내의 공유지식으로 팀차원의 이익으로 승격시킬수 있다는것이다
-
가까이 보면 느리지만, 멀리 보면 가장 빠르다 : 맞다 점점 프로덕션이 커지면 테스트해야할 부분도 커지는데 만약 기능추가하면 모든부분을 테스트를 해야하는 부분이 존재하지만 테스트코드로 자동화한다면 시간을 절약이 가능하다