Controller Test 비즈니스 외 여러 요소 vs 통합 질문좀

[1241235(122.43)]

1. 의존성 mocking하고 정확한 책임만 테스트한다.

2. 통합테스트 한다.

인력이 많은 회사 기준과 인력이 없는 회사 기준 2개에서 뭐가 더 좋을까?

[김대기(waitkim)]

인력이 많으면 둘 다 하고 인력이 적으면 유닛테스트를 추천함 좆같이 만들어서 유닛테스트 답이 안나오면 통합테스트로 메꾸던지

[1241235(122.43)]

인력이 적으면 요청에 대한 모든 밸리데이션 체크가 소요가 많아서 빈 다 끌고와서 E2E테스트로 하는게 좋다고 생각했는데 어떻게 생각해

[프갤러 1(210.183)]

통합테스트는 비싼 테스트야 엔드포인트 테스트는 가짓수도 가장 많아질 수 있고 돌리는데 시간도 많이 들어 니가 말한 체크에 들어가는 리소스와 통합테스트 유지보수 및 평소에 통합테스트 돌리느라 드는 리소스를 비교해보면 답이 나옴 유닛테스트 없으면 작은 코드 하나 수정에도 통합테스트 한번 돌려야할테니까

[프갤러 1(210.183)]

너는 지금 답이 안나오는 상황에 답을 내려고 하고 있어 인력이 부족하면 모든걸 챙길 수 없고 중요한 것 하나만 챙겨야함 통합테스트를 선택해서 과연 생산성이 증대될지 잘 생각해봐

[프갤러 1(210.183)]

그리고 둘 중에 하나만 하는데는 잘 없어 통합테스트로 골든패스만 짜고 나머지는 유닛테스트로 빡세게 커버하지

[프갤러 2(122.43)]

고마워!

[프갤러 2(122.43)]

내가 회사다니면서 테스트 없이 일하니깐 죽을 것 같다고 생각들어서 테스트 관련 책, 강의 많이 듣고있거든 말해준거 적극 반영할께 ㅇㅇ

[익명(211.209)]

테스트 없으니 죽을 것 같다고 하는것이 설계나 구현에 대한 불안함이 큰가보네. 기획이나 스펙이 잘 정해져야하는게 급선무고. 기획팀 통제가안되면 느슨한 구조로 잡는게 중요함. 근데 그거 할 시간이나 여력이 안되는데 + 불안함도 한계치에 다다르면.. => 통합테스트든 유닛테스트든 그 유지보수 코스트 떠안고 하는거지 뭐. 밑 댓글에서 내가 말한것처럼 제한적인 상황에서는 하나로 풀려고하지말고 여러 도구들을 잘 활용하는게 도움되더라고. 화이팅 해 주말까지 일생각하느라 고생이 많네.

[익명(211.209)]

테스트를 할려는 목적이 뭘까? 부터 생각해볼 필요가 있을듯. 일종의 제약을 주는거임. "너 이거 틀리면 너의 앱 구동에 문제가있을걸?" 이라는 시그널임. 1) 저런 제약이 필요한가? 2) 책임만 테스트할정도로 전체 아키텍쳐나 스펙이 가벼운가? 3) 통합테스트의 복잡성을 품어야 한다면, 그정도로 중요한가?

[1241235(122.43)]

오케이 상황따라서 유동적으로 해볼께 고마워 ㅎ.ㅎ

[익명(211.209)]

그래서 정말 케바케인듯. 1) 단순 유틸성, 모듈화가 잘되어있는 케이스들은 의존성 주입으로 2) 데이터 계층에 대한 로직 검증이 꼭 필요한데 마땅한 도구가 없다면 mocking을 도입해서라도 (다만, mocking으로 동작 100% 보증은 못함) 3) 통합테스트를 통해서 플로우에 대한 안정성을 꾀하고싶으면, 적당한 플로우를 잡고 시도해보는것도 나쁘지 않은듯. 누가 어떤의도로 어디서 제약을 추가하여 안정감을 찾고싶은지에 따라 도구가 다양하므로 그거에 맞게 선택하면 됨.

[1241235(122.43)]

아 마지막으로 질문하나만 할께

[익명(211.209)]

나는 BE같은 경우는 비교적 제약이 잘 형성되어있는 형태라 솔직히 어떤 형태든지 Test 쉽다고 봄 FE는 온통 비동기 이벤트들이고 UX와 관련된 케이스가 많고, 다양한 팀의 이해관계가 얽혀있어서 설계자체가 깨질 수 있음. 그래서 차라리 격리나 에러복구에 집중하는게 낫다고 생각하는 편. (근데 다른사람들 말 들어보면 어떻게든 테스트 껴넣으려고 하더라... 그게 코스트대비 도움될까 싶음..)

[1241235(122.43)]

BE파트로 일했는데 FE는 비즈니스 변경 요구사항에 엄청 의존적일 것 같은데(걍 추측임) 테스트가 좀 힘들 것 같네... 근데 내 회사도 기획 변경이 180도 변경하는거라서 BE파트까지도 엎어야되더라구 (내가 회사업무를 이해못하고 족같이 작성한거긴함)

[익명(211.209)]

응 설계가 쉽게 바뀌는 케이스에서는 테스트 코드를 짜기가 쉽지 않음. 내생각엔 테스트 코드란 => 설계가 이미 되어있다는 가정하에 만들 수 있는 런타임 제약 객체라고 해야될까.. (이거 틀리면 앱 배포 금지! 같은 시그널..) 타입제약같은것보다 유연하면서도 실제 앱 코드에는 영향을 안끼치는..

[1241235(122.43)]

아니다 일단 개인 서비스에 적용해보는 거라서 ㅋㅋㅋ 단위든 통합이든 박아보고 리팩토링 경험해볼께

[1241235(122.43)]

여튼 주말인데 쉬어야 하는데 친절하게 답변해줘서 고맙다 ㅎ.ㅎ

[익명(211.209)]

다시말해서, 현재 테스트코드를 못쓰는 환경이라면.. 굳이 테스트코드라기보단 다양한 도구를 고려해볼 수 있음. (1) 격리나 의존성 주입을 잘 활용할것. BE라고 했으니 이거 훨씬 쉽게 할 수 있을거임. (2) 데이터 저장방식에 대한 고려를 먼저 잘 고려할것( 이게 풀리면 그래도 설계 기준 잡기 쉬움) (3) 간단한 모듈 유닛테스트부터 쌓아올리는것도 고려해볼 것 (공용유틸 모듈 하나씩 만들어가며..)

[익명(211.209)]

응 고민해보고 알게된거 있으면 공유해줘