너무나 당연한 이야기이지만 '당연하게'의 기준이 남들과 다를 수 있기 때문에 역시 코드리뷰는 필수다.
테스트 코드를 작성할 때 에러가 발생할 수 있는 케이스들에 대해 깊이 생각하는 습관을 들이자.
고차원의 개념은 저차원의 구현 정보에 무지해야 한다.
개념의 분리를 위해 추상화를 하는 것은 올바르다고 생각하지만 현실적으로 무한히 추상화 단계를 만들 수는 없지 않을까? 내 식견이 짧아서 그렇게 생각되는 걸까?
boolean, enum, int 등의 인수로 함수의 동작을 제어하면 안된다. 케이스별로 함수를 분리하자.
이 부분이 가장 어려운 부분... 코드를 읽어보면 알겠는데 막상 코드를 짤 때는 자연스럽게 나오지 않는다. T와 좀더 친해져야 할 것 같다.
쉬운 내용이지만 급할 때마다 무시되는 경우가 있어서 굳이 기록한다.
마찬가지로 쉬운 내용이지만 급할 때마다 무시되는 경우가 있다.
테스트가 느릴 경우 급할 때 반드시 무시하게 되므로 빠르게 돌아가도록 노력해야 한다.
빠르다, 느리다의 기준은 어느 선에서 정할 수 있을까? 백엔드 Unit Test 러닝타임이 점점 길어지고 있는데 어느 선에서는 mocking을 더 해야할 것 같다.