안녕하세요 신입 개발자 최기환이라고 합니다! 테스트 코드 관련해서 선배님들의 고견을 여쭙고 싶습니다!

1. 질문의 내용 중 "이런 로직을 포함하는 통합적인 로직을 테스트"라고 하는 부분이 잘 이해가 안됩니다. 예를 들어 아래와 같은 간단한 form이 있다고 가정해보겠습니다. ------------------------------ <로그인 폼> <- 로그인 폼은 isFormValid() 함수도 포함하고 있음. <아이디(이메일) 인풋> <암호 인풋> <로그인 버튼> </로그인 폼> ------------------------------ <아이디(이메일) 인풋> -> 얘가 잘 작동하는지 테스트 <암호 인풋> -> 얘가 잘 작동하는지 테스트 여기까진 뭐 토론꺼리가 없습니다만, <로그인 버튼> -> 얘를 클릭했을 때 <아이디(이메일) 인풋>과 <암호 인풋>까지 한꺼번에 통합해서 테스트를 하겠다는 이야기로 들리는데, 왜 그렇게 해야하는지가 이해 안됩니다. 저의 경험에 비춰보면 <로그인 버튼>에 대한 테스트는 "관련된 인풋 값들에 에러가 있을 때" "관련된 인풋 값들에 에러가 없을 때" 정도로 tc를 구성하고, id, pw 인풋은 같이 render 할 필요 없이 걍 있는셈치고(또는 관련된 인풋들의 종류나 갯수는 상관이 없이) <로그인 버튼>만 고립시켜서 테스트가 가능하도록 설계하는게 바람직할 것 같거든요. 위에 제시한 <로그인 폼> 예시 같은 구조라면 <로그인 버튼>을 클릭했을 때 isFormValid()가 호출되고 그 결과에 따라 다음 동작이 결정되는 구조일거고, 그렇다면 isFormValid()를 mocking 해서 상황에 맞게 "항상 true를 반환"하거나 "항상 false를 반환"하게 설정해놓고 그에 맞게 <로그인 버튼>의 동작을 테스트해야 할 거에요. 당연히 isFormValid()에 대한 tc도 따로 작성하고, 만약 전체를 다 담고 있는 <로그인 폼>에 또 다른 기능들이 포함되어 있다면 이에 대한 테스트들도 다 이런 비슷한 느낌으루다가 고립/독립시켜서 수행이 되어야 할 것 같습니다. 이러한 관점에서 보면 질문에 언급된 내용중 "이메일 인풋에서 작성한 테스트는 패스하고"까지는 잘 이해가 되지만 그 뒤에 이어지는 "좀 더 통합적인 테스트"라는 것이 구체적으로 어떤 것을 이야기 하는지 이해가 안 되는 겁니다. 그리고 만약 이렇게 독립/고립시켜서 테스트가 어려운 형태라면 저라면 테스트가 쉬운 형태로 리펙토링 할 것 같습니다. 2. 테스트 작성 순서는 상관이 없을 것 같습니다. 질문 내용처럼 "기능이 완료 되기 전까지는 계속해서 테스트가 실패 할 텐데" 라는 상황은 너무나 당연한 과정입니다. 그 tc fail을 영원히 방치할 생각이 아니라는 전제 하에 말이죠. (당연히 그렇겠죠?) 구현 중인 기능에 제거하기 힘든 외부 의존성이 있다거나 같이 엮여서 돌아가는 연관기능 중에 mocking 하기가 곤란한게 있다거나 하는건 진짜 비일비재 합니다. 그렇기 때문에 이런 저런 이유로 기능이 완성될 때까지 계속 fail하는 tc가 있다면 그건 그렇게 완성될 때까지 진행하는게 맞는 겁니다. 근데 이런 코딩 과정과 별개로 중간 중간 커밋하면서 진행하고 싶은데 팀에 "tc에 fail 있으면 머지할 수 없셈!!" 이런 컨벤션이 있다거나 하다면, tc fail이 없는 내용들만 모아서 따로따로 커밋하고, 최종적으로 기능이 다 완성됐을 때 계속 fail이 발생하던 녀석들을 모아서 막판에 커밋한다거나 또는 리뷰어에게 양해를 구해고 fail 발생하는 tc만 나중에 따로 커밋하는 식으로 할 수 밖에 없습니다. 참고로 저의 경험상 팀의 리뷰/테스팅 컨벤션에 이정도 유연성도 없고 말이 안 통한다면 그건 컨벤션에 문제가 있다고 봅니다.