[테스트 셋업 길드] 테스트 디렉토리 구조, 어떻게 잡는게 좋을까요?

[greatSumini]

본격적인 테스트 코드 작성 전에 구조를 먼저 잡으면 좋을 것 같아 작성합니다 ㅎㅎ

1. 각 파일마다 같은 경로에 동일한 이름의 .[spec|test].ts 파일을 놓는 방식
2. 각 폴더마다 __tests__ 디렉토리를 놓는 방식
3. 루트 경로에 tests 디렉토리를 만들어 src와 동일한 구조로 유지하는 방식

이 있는 것 같습니다!

전 개인적으로 백엔드 작업을 할 때는 첫번째를, 프론트엔드 작업을 할 때는 두번째를, 오픈소스 프로젝트를 만들 때는 세번째를 선호합니다!
세번째 방식이 src와 tests 폴더의 용도가 명확히 구분되기 때문에 온보딩하는 분들의 혼란을 최대한 줄일 수 있어서 오픈소스 프로젝트에 적합하다고 생각합니다 ㅎㅎ
여러분들 의견은 어떤가요 ?.?

[josworks27]

저도 수민님의 의견에 완전히 동의합니다 ! 명쾌하게 정리해 주셔서 감사합니다 ! 👍

[sensecodevalue]

저도 3번이 가장 적합하고 명확하게 확인할 수 있다고 생각합니다!

[jhlee910609]

3번에 한표 합니다. 말씀대로 조금 더 직관적일 것 같습니다!

[p-iknow]

• 저는 tests 폴더 자체가 필요없다고 봅니다. test 코드를 보고 구현코드를 번갈아가며 볼텐데, test 폴더의 존재로인해 코드 읽는 사람은 여러 폴더를 왔다갔다 해야합니다. 이 때문에 __test__폴더를 지양하고 아래와 같은 지역성(localization) 을 우선하는 구조를 제시합니다.

my-project
├── components
│   ├── ProductDetail.tsx
│   └──ProductDetail.test.tsx 
├── remotes
│   └── fetchProducts.ts
│   └── fetchProducts.test.ts
└── utils
    ├── filterProducts.ts
    ├── filterProducts.test.ts

• __test__ 폴더로 달성하려는 목적이 "구분" 이라면 test 파일은 모두 xxx.test.tsx 형식으로 파일명을 통해 구분이라는 목적을 달성하고 있습니다.
• 제가 제시한 방향성의 장점은 응집도가 높아진다는 것 입니다. 폴더 디렉토리안에 테스트와 구현체가 같이 있다보니, 코드 읽는 사람이 쉽게 두 파일을 왔다갔다 할 수 있습니다.

관련 레퍼런스

@greatSumini @jhlee910609 @sensecodevalue @josworks27

[josworks27]

@p-iknow

좋은 의견과 레퍼런스 감사합니다. 선택하는데 있어 가장 중요한 기준이 되는 것은 누구를 위한 것인가(타겟) 인 것 같습니다.
이에 따라, 저희 라이브러리가 기준으로 삼아야할 대상의 설정을 명확히 할 필요가 있어 보입니다.

참고 하기 위해 저희 라이브러리와 성격이 유사한 몇 가지 오픈소스 라이브러리들을 조사해 본 결과, 대체로 오픈소스 라이브러리에선 루트에 테스트 코드를 분리하는 경향이 강하였습니다. 조사 대상은 아래와 같습니다.

./tests에 테스트 코드가 존재하는 유사 라이브러리 목록

• react-ga
• react-analytics
• electron-google-analytics
• @frontity/google-analytics (모노레포로 구성되어 각 패키지 루트에 tests 존재)

대체로 이러한 경향을 갖고 있다는 것이지 반드시 이렇게 해야할 필요는 없을 것으로 생각됩니다. 따라서 각각의 방식의 장/단점을 명확히 알고 사용하는 것이 중요해 보이며, 이와 관련하여 위클리에 짧게나마 논의해 보는 것도 좋을 것 같습니다.

[greatSumini]

@p-iknow 좋은 의견 감사합니다 ㅎㅎ
저는 오픈소스 프로젝트에서는 지역성보다는 가독성을 중시해도 좋겠다고 생각합니다! 이유는 다음과 같습니다.

1. 오픈 소스는 '테스트 파일과 소스 파일을 왔다갔다하며' 코드를 읽는 사람의 비중이 기업 프로젝트에서보다 현저히 적을 것이라고 생각합니다. 왔다갔다하며 테스트 파일을 작성하는 사람은 더 적을 것이구요.
   따라서 테스트와 소스파일을 완전히 분리해 파일탐색기 내에서의 가독성 및 간결함을 높이는 편이 좋을 것 같습니다.
2. 누구나 기여할 수 있는 오픈소스 프로젝트 특성상 미리 정의된 building block들의 역할이나 각 디렉토리의 구분 등이 흐릿해질 가능성이 기업 프로젝트에 비해 높다고 생각합니다. 테스트 파일 작성에 대한 규칙?도 시간이 지남에 따라 제대로 지켜지지 않을 가능성이 높구요 😢 이로 인해 코드베이스가 거대해졌을 때 모든 디렉토리가 테스트 파일도 같이 포함하고 있다면 온보딩하는 사람 입장에서 파악하기 어려울 수 있겠다고 생각합니다.
   아래 사진은 vercel/next의 lib 디렉토리입니다. 만약 각 소스파일의 테스트 파일이 동일한 경로에 작성되었고, 어떤 파일은 테스트가 있고 어떤 파일은 없다면 읽는 사람 입장에서 방대하고 막막하게 느껴질 수도 있을 것 같습니다 😭
   

[p-iknow]

@greatSumini @josworks27
^ 의견에 동의합니다. 말씀해주신 부분에 설득되었습니다. 저는 이의없고, 그렇다면 3번!!

[uoon-dev]

재직 중인 회사 프론트 팀에서도 테스트와 구현체가 같은 폴더 안에 있는 방식을 선호해서 그렇게 작업하곤 있는데, @greatSumini 님이 말씀해주신 것처럼 오픈소스의 특성을 고려해보면 3번 방향이 좋을 것 같네요. No Objection 입니다 :p

[greatSumini]

3번으로 최종 결정되었습니다 😃

[milooy]

앗 뒷북 죄송

오픈소스의 테스트는 서비스 코드와 밀접하게 연결되어있는 중요한 부분이고 더 나아가선 스펙정의 역할도 하는걸 생각해보면
한폴더에 있는것도 좋을거같아요 ㅋㅋ

장점:

• 서비스코드를 고칠 때 테스트를 유심히 볼 수 있다 (가까이 있어서)
• 라이브러리 코드마다 테스트를 꼭 넣으려는 마음이 든다 (뭉쳐있으면 테스트가 있는지 없는지 확인하기가 어려움 - 물론 coverage등으로 해결할 수 있습니다)

But...
이 구조를 강제하지 않는 이상 말씀해주신 우려사항

어떤 파일은 테스트가 있고 어떤 파일은 없다면 읽는 사람 입장에서 방대하고 막막하게 느껴질 수도 있을 것 같습니다 😭

이 발생할 수 있겠네요...
일단 3번으로 해보고 이슈 없는지 유심히 살펴봐요~ 🙇
디스커션 꺼내주셔서 감사합니다 ㅎㅎ