JS test란
Last updated
Was this helpful?
Last updated
Was this helpful?
JS 테스트를 왜 할까?
작업 흐름 속도를 올려서 개발을 빠르게 한다.
변경 사항이 있을 때 기존 코드를 무너트리지 않는다는 확신을 갖도록 도와준다.
너무 많이는 말고.
커버리지 100%는 좋은 생각이 아니다. 70%(저자의 추측)를 넘어가면 서부터 테스트로 얻는 이득 감소.
테스트 환경에서 재현하기 어려운 한 줄의 코드를 위해 테스트를 작성할 수도 있다. 이런 경우는 피하고 싶다. 왜냐면 이 테스트는 애플이케이션이 제대로 작동한다는 자신감을 주지 못하고, 리팩터링 속도를 늦춘다. 코드를 리팩터링 할 때 테스트를 변경해야 하는 경우는 거의 없다.
통합 테스트를 많이 써라.
피라미드의 위로 올라갈수록 테스트를 실행하고 작성하는데 더 많은 시간이 들고, 실행하고 유지보수하는데 비용(시간과 자원 측면에서)이 많이 듭니다. 그림만 보면 유닛 테스트를 작성하는데 시간을 더 투자해야 하는 것 처럼 보입니다.
유닛 테스트만 좋아하는 사람들의 테스트 모양 자신의 다양한 신체 부위를 아주 효율적으로 사용하지 못하는데다 통합하지 않고 있습니다.
각각 분리 된 부분이 자신의 역할을 제대로 수행하는지 확인하기 위해 단위 테스트를 작성하는 것은 그리 나쁜 일은 아닙니다. 분리 된 부분이 함께 제 역할을 수행하는지 확인하지 않는다면 아무 소용 없습니다.
통합 테스트는 자신감을 심어주는 역할 대비 속도/비용을 부담하는 정도를 아주 균형있게 가지고 있습니다. 그래서 여러분이 대부분(혹시 몰라 말씀드리지만 전부는 아닙니다)의 시간을 통합 테스트에 투자하라는 조언을 드리는 겁니다.
일단 너무 많은 것을 모킹(mocking)하지 않기를 권합니다. 만약 리액트로 개발을 하고 계시다면, 얕은 랜더링(shallow rendering)도 포함됩니다. 저는 오랜 시간동안 얕은 랜더링은 세부 구현을 테스트하는 것이나 마찬가지라고 이야기해왔습니다. 이 부분을 3분 짜리 팟캐스트에서(그리고 리액트 테스팅에 대한 다른 팁도 포함해서) 다루고 있습니다.
