JS test란

JS 테스트를 왜 할까?

1. 작업 흐름 속도를 올려서 개발을 빠르게 한다.

2. 변경 사항이 있을 때 기존 코드를 무너트리지 않는다는 확신을 갖도록 도와준다.

테스트를 작성하라. 많이 말고. 통합 테스트를 많이 써라.

너무 많이는 말고.

커버리지 100%는 좋은 생각이 아니다. 70%(저자의 추측)를 넘어가면 서부터 테스트로 얻는 이득 감소.

테스트 환경에서 재현하기 어려운 한 줄의 코드를 위해 테스트를 작성할 수도 있다. 이런 경우는 피하고 싶다. 왜냐면 이 테스트는 애플이케이션이 제대로 작동한다는 자신감을 주지 못하고, 리팩터링 속도를 늦춘다. 코드를 리팩터링 할 때 테스트를 변경해야 하는 경우는 거의 없다.

통합 테스트를 많이 써라.

피라미드의 위로 올라갈수록 테스트를 실행하고 작성하는데 더 많은 시간이 들고, 실행하고 유지보수하는데 비용(시간과 자원 측면에서)이 많이 듭니다. 그림만 보면 유닛 테스트를 작성하는데 시간을 더 투자해야 하는 것 처럼 보입니다.

유닛 테스트만 좋아하는 사람들의 테스트 모양 자신의 다양한 신체 부위를 아주 효율적으로 사용하지 못하는데다 통합하지 않고 있습니다.

각각 분리 된 부분이 자신의 역할을 제대로 수행하는지 확인하기 위해 단위 테스트를 작성하는 것은 그리 나쁜 일은 아닙니다. 분리 된 부분이 함께 제 역할을 수행하는지 확인하지 않는다면 아무 소용 없습니다.

통합 테스트는 자신감을 심어주는 역할 대비 속도/비용을 부담하는 정도를 아주 균형있게 가지고 있습니다. 그래서 여러분이 대부분(혹시 몰라 말씀드리지만 전부는 아닙니다)의 시간을 통합 테스트에 투자하라는 조언을 드리는 겁니다.

통합 테스트 더 많이 작성하기

일단 너무 많은 것을 모킹(mocking)하지 않기를 권합니다. 만약 리액트로 개발을 하고 계시다면, 얕은 랜더링(shallow rendering)도 포함됩니다. 저는 오랜 시간동안 얕은 랜더링은 세부 구현을 테스트하는 것이나 마찬가지라고 이야기해왔습니다. 이 부분을 3분 짜리 팟캐스트에서(그리고 리액트 테스팅에 대한 다른 팁도 포함해서) 다루고 있습니다.