여행 어디다녀오셨나요.. 저도 여행 보내주세요
이사도 가셨군뇨 이사 힘들죠.. 고생많으셨어요. 이제 미션 완주해볼까요 ㅎㅎ ㅋㅋㅋ

UI 테스트는 UI에 대한 관심사만 테스트하는 것이 맞는 것 같아서, 에러 문구가 띄어지는 경우의 수만 테스트했습니다(그게그건가요..?)

많이많이 고민해보세요!
지금은 컴포넌트 자체가 단순해서 그리 많은 테스트를 작성하긴 어렵다 생각해요.

입력창 컴포넌트를 하나 잘 만들어두었으니, 이 컴포넌트를 활용해서 각 입력(이메일, 비밀번호 등)에 맞는 컴포넌트를 각각 만들어보는 건 어떨까요?

각 컴포넌트들은 Preview와 함께 파일 분리해보는 건 어떨까요?

현재 리뷰의 방향들은 공용 컴포넌트를 추출하는 과정일까요?
특정 UI 혹은 커스텀이 필요한 TextField가 아니라면,
TextField(Material) -> Public TextField(공용) -> Private TextField(이메일, 비밀번호 등)
3번씩이나 wrapping 해야하는 이유가 무엇인지 궁금합니다!

Screen을 통째로 테스트해볼 수도 있겠지만,
각 입력 타입별 입력기 컴포넌트를 만들어본 다음, 각각의 컴포넌트에 대해 테스트코드를 작성해보는 건 어떨까요?
각 컴포넌트들이 서로의 간섭 없이 테스트를 만들어볼 수도 있겠어요 :)

private한 함수를 테스트하는 방법으로 해당 함수를 사용하는 Public 테스트를 테스트함으로써 간접적으로 테스트 할 수 있었습니다.
비슷하게 SignupScreen함수를 통해 screen 함수 내부의 private 함수들을 테스트하도록 구현했는데 맞는 방법일까요?
공용 컴포넌트가 아님에도 테스트만을 위해 public, internal로 두어야하나요?

테스트 코드의 검증부에는 상수를 활용하기 보다, 문자열을 직접 하드코딩하는 건 어떨까요?
좋은 글을 공유드려요 :)

좋은 글 감사합니다! 글을 정독해보았을 때 1, 2번에 대한 내용에 공감했습니다!
하지만 구현된 테스트는 UI 테스트이며, description에 언급했듯 문자열 혹은 상수값 등 content에 대한 내용이 중요하지 않다고 생각합니다!
만약 중요했다면 오히려 실제 UI 로직에서 사용하는 상수값을 같이 사용해야 불일치 문제가 일어나지 않을 것 같아요
실제 content에 들어갈 내용들은 유닛테스트를 통해 검증하고 UI는 해당 content가 들어갈 UI(에러 Text)가 잘 '표기'되는지가 주 관심사라고
생각합니다! 관련해서 마침 슬랙에 토론이 열렸더라구요!
제 생각은 영직님께서 올려주신 NIA 방법이 적절하다고 생각하는데 말리빈님 생각은 어떠신지 궁금합니다!

처음부터 17자 문자열을 사용하지 않고 9자리 문자열을 더해서 쓰는 큰 이유가 있었나요 ?_?
어떤 의도인지 궁금해요.

17자를 쉽게 카운트하려고 그랬던 것 같습니다 ㅋㅋ; 수정했습니다!

현재 리뷰의 방향들은 공용 컴포넌트를 추출하는 과정일까요?
특정 UI 혹은 커스텀이 필요한 TextField가 아니라면,
TextField(Material) -> Public TextField(공용) -> Private TextField(이메일, 비밀번호 등)
3번씩이나 wrapping 해야하는 이유가 무엇인지 궁금합니다!

공용 컴포넌트라..
컴포즈는 컴포넌트를 만들어내기 아주 쉬운 툴이라 생각해요.
잘 만들어둔 컴포넌트는 언제든지 손쉽게 재활용할 수 있다는 장점이 생겨나지요. 중복 코드를 비약적으로 줄여낼 수 있다는 장점은 덤이구요.
이런 툴을 이용해서 컴포넌트를 잘 뽑아내는 연습이 되었으면 좋겠어요.

다른 화면에서 이메일 입력창이나 비밀번호 입력창이 필요해지는 경우, 그때 되어서 컴포넌트 분리를 해볼 수도 있겠지요!
개발 하면서, 컴포넌트 분리 되어있지 않았는데, 나중에 필요해서 재활용 해야하는 경우 화가 나더라구요.
아 거 좀 분리좀 해놓지 ^________^
제가 조금 더 신경 써 놓으면 다른 동료들이 더 편하게 쓸 수 있는 것들이 생산성을 높혀주기도 하더라구요.

말이 좀 길었는데,
미션은 학습을 위한 것이니, 어디까지 컴포넌트로 분리해볼 수 있을까? 를 유념하면서 의미있는 컴포넌트를 만들어내는 것을 목표로 잘 분리해보셔도 좋겠어요.
물론 불필요하다 생각이 든다면, 분리하지 않으셔도 좋아요!

private한 함수를 테스트하는 방법으로 해당 함수를 사용하는 Public 테스트를 테스트함으로써 간접적으로 테스트 할 수 있었습니다.
비슷하게 SignupScreen함수를 통해 screen 함수 내부의 private 함수들을 테스트하도록 구현했는데 맞는 방법일까요?
공용 컴포넌트가 아님에도 테스트만을 위해 public, internal로 두어야하나요?

이 리뷰는 컴포넌트 분리와 연결되어요.
컴포넌트 분리가 되어있지 않으면, 현재 처럼 Screen을 테스트하는 것이 올바른 방법이겠지요!

좋은 글 감사합니다! 글을 정독해보았을 때 1, 2번에 대한 내용에 공감했습니다!
하지만 구현된 테스트는 UI 테스트이며, description에 언급했듯 문자열 혹은 상수값 등 content에 대한 내용이 중요하지 않다고 생각합니다!
만약 중요했다면 오히려 실제 UI 로직에서 사용하는 상수값을 같이 사용해야 불일치 문제가 일어나지 않을 것 같아요
실제 content에 들어갈 내용들은 유닛테스트를 통해 검증하고 UI는 해당 content가 들어갈 UI(에러 Text)가 잘 '표기'되는지가 주 관심사라고
생각합니다! 관련해서 마침 슬랙에 토론이 열렸더라구요!
제 생각은 영직님께서 올려주신 NIA 방법이 적절하다고 생각하는데 말리빈님 생각은 어떠신지 궁금합니다!

정답이 없는 부분이어서, 선택에 맡길게요.
저는 하드코딩 하는 것을 선호해요.
우선 바로 테스트 코드를 읽어서 무슨 내용인지 눈에 잘 들어오는 테스트의 형태를 가장 선호해요.
테스트를 읽기 위해서 다른 코드의 구현체로 넘어가는 것 자체를 그리 좋아하지 않아요. 이미 읽는 흐름이 끊겨버린다 생각해요.
물론 너무 길어서 흐름을 끊어놔야 읽기 좋게 되는 테스트도 존재하겠지요.

'잘 표기'해야한다는 의미는, 정확한 단어가 들어가야한다는 것과 다르지 않다 생각해요.
문자열 마이그레이션이나, 누군가의 실수 등으로 상수 자체가 공백 등으로 바뀌거나 한다면, 테스트는 바로 통과되겠지요.
거짓 통과야 말로 가장 테스트에서 피해야 할 요소이지 않을까 생각해요.
테스트를 신뢰하지 못한다면, 더 이상 작성하지 않을테니까요.