- 테스트를 작성하다보면 생기는 고민 포인트
무엇을 모킹해야 할지, 얼마나 많이 모킹을 해야할지
테스트를 통해 얻을 수 있는 가장 큰 가치는 [언제 테스트가 실패해야 하는지](https://www.epicweb.dev/the-golden-rule-of-assertions) 아는 것입니다.
- 테스트 하려는 것이 외부의 무언가에 영향을 받아 실패하면 안된다
- 예를 들면 서버 요청/응답을
- 테스트 작성했을때 무슨 이유로 네트워크 오류가 발생한다면 테스트가 실패하게 된다
- 이는 의도와 다르게 실패하게 되는 것으로 테스트 경계를 다시 설정하여 테스트 하려는 범위를 수정해야한다
네트워크가 테스트 결과에 영향을 미치지 않도록 하는 것입니다. 서버의 작동 가능성 및 정확성은 테스트된 함수의 관심사가 아닙니다. 함수는 서버에 영향을 미치지 않으며 그 동작을 보장할 수 없습니다. 따라서 테스트 코드의 관심 밖에 있는 사항으로 인해 테스트가 실패해서는 안 됩니다.
- 테스트 하려는 것이 아니라면 모킹 하면 되는데, 다시 첫번째 고민 포인트로 돌아온다
- 어느 정도로 모킹을 해야할까?
테스트 경계는 테스트에서 중요하지 않은 것을 결정하는 데 도움이 되므로, 테스트 경계를 과도하게 설정하면 실제로는 아무것도 테스트하지 않아 아무것도 중요하지 않은 테스트가 됩니다. 이를 종종 *오버모킹*이라고 하는데, 이는 절대 도달하고 싶지 않은 상태입니다.
- 이 테스트가 언제 실패야하는건지 생각해보고
- 성공과 실패하는 상황에 필요한 변동 조건이 아니라면 모킹 처리해본다
코드의 복잡성과 테스트 설정의 복잡성 간의 관계- 코드는 단순하지만 테스트 하기에 복잡한 그러한 경우가 있다
- 생각나는 것은 파라미터가 엄청 큰 객체를 전달 받아 수많은 프로퍼티들을 사용하는 경우가 그러하다
- 이 경우 다양한 케이스에 대해 검증하기 위해 수많은 형태의 테스트를 작성해야한다
- 또는 모킹으로 처리하더라도 동일하다..
- 이러한 복잡성을 해결하기 위해 코드가 필요로하는 최소한의 파라미터를 받도록 정리한다
- 객체에서 뽑아낸 프로퍼티 보다는 숫자로 하나를 전달 받는게 간단하기 때문이다
- 테스트 커버리지를 채우기 위해 남아있는 브랜치를 실행하는 테스트를 작성하지 말고
- 사용자 관점에서 테스트 케이스를 작성하고나서 실행되지 않는 브랜치에 대한 코드를 재작성 하는 것을 고민해봐야한다
- 테스트를 작성하는 이유가 서비스가 안정적으로 동작하기 위함이기 때문에
- 사용자 관점에서 동작하는 케이스들을 테스트 작성하는 것이다
__brand 프로퍼티로 같은 string 타입의 값이지만 다른 string 이 들어가는 것을 구분할 수 있게 한다
- 충격적인 내용들이였다
- 벤치마킹을 할 수 있다면 당장 시도해봐야하는 것들이 잔뜩이다
- 문자열 비교 대신 아이디를 비교하도록 하고
- O(1) 이라고 생각했던 인덱스 찾아 비교하는 것도 문제가 될듯하다
- 체인형으로 함수를 쓰는 것이 이쁘기는 하지만 최적화는 되지 않는것이 사실이다