Chapter 04 - 테스트 구축하기

인상깊은 문장, 코드들

프로그래머들이 어떻게 일하는지 가만히 살펴보면 실제로 코드를 작성하는 시간의 비중은 그리 크지 않음을 발견할 수 있다.
프로그래머라면 누구나 꼬박 하루를 (혹은 그 이상을) 잡아먹은 디버깅 무용담을 하나씩은 간직하고 있을 것이다. 버그 수정 자체는 대체로 금방 끝난다. 진짜 끔찍한 건 버그를 찾는 여정이다. 또한 버그를 잡는 과정에서 다른 버그를 심기도 하는데, 그 사실을 한참이 지나서야 알아채기도 한다. 그래서 또다시 그 버그를 찾느라 수많은 시간을 날린다.

일부 프로그래머들이 선호하는 public 메서드를 빠짐없이 테스트하는 방식과는 다르다. 명심하자! 테스트는 위험 요인을 중심으로 작성해야 한다! 테스트의 목적은 어디까지나 현재 혹은 향후에 발생하는 버그를 찾는 데 있다. 따라서 단순히 필드를 읽고 쓰기만 하는 접근자는 테스트할 필요가 없다. 이런 코드는 너무 단순해서 버그가 숨어들 가능성도 별로 없다.
나는 적은 수의 테스트만으로 큰 효과를 얻고 있다. 잘못될까봐 가장 걱정되는 영역을 집중적으로 테스트하는데, 이렇게 해서 테스트에 쏟는 노력의 효과를 극대화하는 것이다.
완벽하게 만드느라 테스트를 수행하지 못하느니, 불완전한 테스트라도 작성해서라도 테스트를 수행하는 게 낫다.

TDD나 테스트 코드에 대한 기대와 선망은 높지만 프런트엔드에서 실제로 적용하는 것이 어떤지에 대해서는 잘 모르겠다. 컴포넌트를 테스트 한다면.? 책에 따르면 중요한 곳만 테스트하면 된다고 했으니 수량 변경 (최저 수량, 최대 수량, 구매 제한 정책 등) 컴포넌트, form validation 컴포넌트 등에 적용해볼만 할까? 수량의 경우는 그나마 테스트하기가 쉬울 것 같다. 그럼 다크모드, 모바일, 중간 사이즈 태블릿, PC 등은 테스트 코드로 어떻게 잡을 수 있을까? 로지컬하게 input output만 잡을 수 있는 테스트에 비해서는 확실히 어렵고 낯설다. PlayWright 등에서는 visible 등의 속성을 활용할 수는 있겠지만 버튼 위치, border 여부 등까지 고려한다면 테스트 자체가 일단 일이다.
1 pass 0 failing 표시해주는 자가 테스트 자체가 이 당시에는 혁신이었나보다.
테스트는 위험 요인을 중심으로 작성!
Vue vs React 테스트 용이성? 결론적으로, React와 Vue는 모두 테스트하기 용이하며 강력한 테스팅 도구와 유틸리티를 제공합니다. 선택하는 것은 주로 개인의 선호나 프로젝트의 요구 사항에 따라 달라질 수 있습니다. by GPT