단위 테스트의 효용성에 대한 질문

Question

다른 테스트 코드는 작성 안해도 단위 테스트는 작성하는 곳들이 많은데요.단위 테스트는 다른 코드들과의 의존성을 배제하고 테스트하려는 부분의 로직만 테스트 하잖아요.이렇게 되면 테스트의 의미가 해당 코드를 나포함 누군가가 잘못 건드려서 원하는 로직대로 작동하지 않을 때 알아채는 효과 밖에 없잖아요.이거는 코드 리뷰만 잘 해도 어느정도 해결될 수 있는 부분인데 이거 때문에 테스트 코드를 빡빡하게 작성해야 하는지 의문이 드네요.그리고 보통 원래 코드를 변경할 때는 아예 로직 자체가 변경되는 경우가 많아서 테스트 코드 자체도 또 수정해줘야 하는 경우가 많을꺼구요.결국 기존 코드의 로직들은 그대로 두고 리팩토링하고 확인할 때 또는 누가 코드 잘못 건드렸을 때 알아차림 정도의 용도인데 누가 코드 잘못 건드리는 것도 각자 건드릴 수 있는 영역을 확실히 나누면 해결될 일이라 보여요.이 정도 효과를 위해서 단위 테스트라는 것에 리소스를 투입해야 하는건지 의문이 드네요.

yeori · Answer

님은 꼭 단위테스트 짜야 할 거 같아요.

chytonpide · Answer

캐바캐입니다. QA를 하는게 효율적인경우도 있고 유즈케이스가 적으면 전부 e2e테스트로 커버할 수도 있지요. gui작성할때 유닛테스트는 잘 안만들잖아요. 비용이 너무 비싸니까요.하지만 일반적으로 코드베이스가 커지고, 개발자도 많아지면 님이 후술한 나쁜 효과들이 걷잡을수 없이 커지고 컨트롤이 안돼요. 휴먼에러도 훨씬 많아지구요. 유닛 테스트가 있으면 이런 상황을 완화할 수 있어요. 유닛테스트는 만드는 비용이 적은 한편, 코드베이스가 커지면 이점이 복리로 돌아오는 샘이에요.또 다른 이점으로는 유닛테스트 자체가 로직 빨리이해할 수 있게 도와주는 가장 좋은 문서로 기능할 수 있어요. 입력과 기대되는 출력만큼 로직을 정확하게 설명하는게 없지요. 또 테스트를 작성하다보면 뭔가 작성이 너무 힘들다는 느낌이 들때가 있는데요. 이런경우 대부분 인터페이스가 적절히 분리되어있지 않다는걸 깨닫게돼요. 테스트를 작성하다가 얻은 인사이트가 더 좋은 설계로 이어지는 경우가 빈번해요.

カワウソ · Answer

이슈가 발생했을때 관련 비즈니스 로직을 확인할 단위 테스트 코드가 없다는 부분이 아쉬움으로 다가올 때가 많음QA 통합 테스트는 요구사항의 통과 여부만 확인할 뿐 상정 외 케이스를 체크하지는 않아요.

스토리 · Answer

어느정도의 단위 테스트는 말씀하신 부분을 커버할 수 있습니다.코드 리뷰가 항상 잘 동작할 수 있는 확신이 없습니다. 사람이라 실수를 할 수 있고, 수정 사항이 많으면 추적할 수 없기 때문에테스트 코드가 수정이 되어야 한다면, 100% 그런 것은 아니지만 구조적인 문제를 고민 해봐야 할 것 입니다. 새로운 테스트 코드가 추가되는 케이스가 아니라, 테스트 코드가 바뀌는 경우라면 초기 개발 단계를 제외하곤 경험상 잘 변경되지 않더라구요.리팩토링 시 검증할 수 있는 게 장점 입니다. 테스트 코드를 작성했다면, 보통 인풋 혹은 동작을 넣고 아웃풋 혹은 동작에 대한 검증을 할텐데, 리팩토링 시에 유닛 테스트 검증을 통해 안정적인 리팩토링이 가능합니다.물론 유닛 테스트가 절대 모든 걸 커버하진 않아요, 코드 커버리지, 테스트 커버리지 100%는 허황이라고 생각하구요, 하지만 중요한 기능 등의 검증은 개인적으로 필요하다고 생각합니다.

보름 · Answer

코드리뷰 아무리 잘해도 리뷰한데로 구휜되지 않은 경우도 많습니다.거짓으로 완료보고 올리는 개발자들도 많구요.심지어 퍼불에게 받은 화면이 뜨는거만 보고 완료보고 올려놓고, 그거 검수 안해준다고 따지는 개발자도 있었습니다.그리고는 감당 안되면 개발 도중 도망가버리구요.이게 현실입니다.통테보다 중요한게 단위테스트입니다.단위테스트없는 통테는 아무 의미가 없어요.

앙두 · Answer

테스트 코드 자체로 기술명세서 역할도 하고 개발할 때 마다 포스트맨으로 잘되는지 테스트할거 아니잖아요

xml개발자 · Answer

돈주는 사람 입장에서 생각해보세요.10억을 주고 프로젝트를 맡겼는데, 테스트를 했다는 증거가 없다면...

감독님테스트가하고싶어요 · Answer

결국 기존 코드의 로직들은 그대로 두고 리팩토링하고 확인할 때 또는 누가 코드 잘못 건드렸을 때 알아차림 정도의 용도인데 누가 코드 잘못 건드리는 것도 각자 건드릴 수 있는 영역을 확실히 나누면 해결될 일이라 보여요.약간 오만한 생각입니다.위의 상황에서 쫌만 더 복잡해지면 기존 코드는 건드릴 수 조차 없습니다.기존 코드의 수정이 아니라 새로 만드는 영역이 되겠죠. 왜냐면 그게 편하니까아니면 들이는 시간을 배로 들이던가요리펙토링할때 테스트 없으면 그떄가서 테스트 만들고 리펙토링하면 된다고 생각할수도 있는데 그때가서 테스트 작성하는거 자체가 또 코드 분석이라는 리소스가 들어가서 비효율 그 자체임

집킨 · Answer

코드를 작성하는 모든 행위는 "사람" 이 하기 때문에 단위 테스트는 꼭 필요합니다이상적으로 작업하는 사람끼리 잘 약속해서 진행하면 단위 테스트가 꼭 필요하냐 라고 생각할 순 있겠지만,결국 하나둘씩 빵꾸 뚫리고 결국 레거시가 되는 수순은 100% 입니다

한안아 · Answer

1.개발하면서 테스트2.단위테스트3.통합테스트4.오픈기본적으로 개발하면서 기본테스트를 하고 이후 단위테스트도 진행하여 포로세스 상에 일반적인 오류가 안나도록 하는게 정상입니다.통합테스트에서는 단순 오류가 나서는 안되며 (날수도있지만 기본적인 테스트도 안했다는 소리) 보통 데이터의 정합성이나 특수한 케이스에 대한 오류를 잡는 용도임.고로 단위테스트는 꼭 필요합니다.이거 안하면 통합테스트에서 감당할수 없는 만큼의 오류가 생성되고 그건 그 프로젝트의 수준을 결정하게됨

세브라이드 · Answer

경험상 프로그램을 코어 - 뷰(혹은 엔트리포인트) 로 명확하게 나눌 수 있으면 단위 테스트가 많이 도움이 됩니다.얘를 들어 모든 뷰단이 코어의 반응형 뷰로 이루어진 서비스가 있다고 가정해보죠. 이런 프로그램이 있다면 코어의 단위 테스트를 꼼꼼하게만 해놓으면, 뷰는 가끔 반응이 느리거나, 액션이 가끔 먹통이 될 수는 있어도 뷰에서 생긴 버그가 코어까지 전파되기는 어렵습니다.또 하나, 코어만 빡세게 테스트를 돌리면 뷰단은 어련히 잘 동작하겠지 하고 넘어갈 수도 있죠. 어떤 프로그램은 휴먼 테스트에만 백시간(플탐 백시간짜리 게임이라던가)이 걸리는 경우가 있을텐데 그런 테스트를 최소화할 수 있다면 아주 도움이 되죠.'여기서부터 여기까지는 확실히 분리가 잘 되어있다!'하는 부분만 단위테스트 하는게 효율적입니다.

장독깨기 · Answer

단위 테스트는 내가 만든 모듈이 로직에 이상이 있는지 없는지 개발자 레벨에서 테스트 하는 겁니다.그니까, 개발자가 이 모듈에 단위 시험이 필요한지 아닌지 판단하면 될 거 같습니다.가령, 테스트 케이스 하나짜리 같은 하나마나한 테스트는 굳이 시간들여 할 필요 없다 생각합니다.전 단위 테스트 거의 만들지 않습니다. ㅎ

삽살개발 · Answer

기존의 코드에 대한 사양서가 될수 있습니다.리소스(비용)란건 코드 수정 배포로 갈수록 커집니다.

단위 테스트의 효용성에 대한 질문

13개의 답변

Q&A 목록