테스트 코드 TDD

Question

테스트 코드 작성 쪽이 많이 부족해서 공부를 하려고 인프런에서 강의를 결제를 했습니다. 강의 내용을 잘 이해하고있다가 tdd에 대해 소개를 하더군요. 이전에 제가 잠깐 회사 공고에서 tdd를 사용해본 경험에 대한 사항이있었던것 같아서 tdd에 대해 공부하고있었습니다. 강의에서는 물론 간단한 상황이라서 테스트 코드를 먼저 작성하고 이런게 가능한것 같은데 실제로 복잡한 도메인에서 가능할까? 라는 의문도 생겼습니다. 또한 tdd도 많은 개발 방법론 중 하나이기에 정답은 아니라고 생각하고 아래 유튜브를 보면서도 tdd가 정답이 아니구나란걸 생각하게됩니다. 테스트 코드를 어떻게 작성하는게 공부 할 수록 방향성을 잃고있네요ㅠㅠ 혹시 어떤식으로 테스트 코드를 작성하는게 좋을 지 자문을 구하고싶습니다. 아니면 블로그나 영상을 알려주셔도 감사드립니다!!https://www.youtube.com/watch?v=gs1qM1TF5zA&t=1s

manijang2. · Answer

테스트나 TDD에 대해서 아직 잘 모르셔서 방향을 잃은게 아닐까 싶습니다.예를 들면 숲을 봐야 하는데, 수많은 나무를 보다보니 숲을 못보는게 아닐까 싶습니다.처음에는 참나무를 보며 숲은 참나무로 구성되어 있구나, 생각했는조금 가보니 소나무가 있고, 은행나무가 있고, 단풍나무가 있고..그래서 처음에 숲은 참나무 였지만 점점 숲의 다양한 점을 보며 숲의 정의를 못내리는가 싶네요.아래 그래프에서 절망의 봉우리가 아닐까 생각이 들며, 이제 자기 나름대로 정의를 적립해보시면 될 것 같습니다 ㅎㅎ

집킨 · Answer

실제 돈을 가져다주는 복잡한 비지니스에서 tdd는 예상하신대로 현실적인 문제와 부딪힙니다(단순히 테스트 코드를 작성하는게 아니라 테스트 코드를 먼저 작성하고 비지니스 로직을 채우는 tdd를 말씀드린겁니다)일단 이게 현실적으로 가능할까를 배제하고 간단한 로직부터 해보세요

개발 까마귀 · Answer

그냥 한번 실무에서 써보면서 부딪혀보는거를 추천드립니다. 머리속으로나 강의로만 느끼기에는 한계가있어요 최고로 좋은거는 한번 써보는겁니다. TDD 반대하는 사람들도 다 써보고 "이런 점에서는 안되더라" 하는 거에요 100% 안좋다는 아닌거죠

nippori · Answer

개인적으로 이렇게 실사용 예제가 궁금할때 유명 테크 기업들의 테크블로그, 유튜브 채널들을 이용합니다. 예를들어 유튜브에 tdd kakao 로 검색하면 tdd를 실무에 어떻게, 왜 적용했는지 같은 내용을 간접적으로 배울수 있고요.면접에서 tdd관련 얘기가 나온다면 간단 명료하게 왜 쓰는지, 써본 경험, 장&단점 정도 깔끔하게 말할정도만 준비해도 면접 답변으로는 문제 없을것 같습니다.

wharup · Answer

ㅎㅎ 저는 TDD 포함해서 테스트 작성이 충분히 가치가 있다고 생각합니다.시작하는 단계에 맞지는 않을 수도 있지만 제가 가장 좋아하는 관련 영상입니다.산드로 만쿠소라고 소프트웨어 장인정신 책 저자이고 관련해서 활동이 많으신 분입니다.Testing and Refactoring Legacy Code (한글 자막 있음)https://amara.org/videos/5qeTm2IuDCAW/info/testing-and-refactoring-legacy-code/

Kyeongrok Kim · Answer

tdd를 한다고 생각하면 Test Code를 짤 수 있게 코드를 관절을 만들어서 짜야합니다. 그러다 보면 객체의 책임, 역할에 대해 고민 해보게 됩니다.Dependency에 대해서도 고민하게 되구요. 테스트가 돌아가도록 만들기 위해 TDD를 한다고 토비의 스프링3에도 나와있습니다.이렇게 작성된 테스트 코드는 이후에 변경에 대한 Side Effect를 배포하기 전에 잡아줍니다.복잡한 기능일 수록 클래스에 역할 분배를 잘 해야 하기 때문에 TDD가 유용합니다.시간을 꽤 많이 걸리니까 팀장님께 잘 얘기 하셔야 합니다ㅎㅎ

정규분포 · Answer

주제에 벗어난 얘기지만: 특히 로우 레벨로 내려가면 내려갈 수록 TDD 적용하기 거의 불가능에 수렴합니다. 커널 개발이 특히 그럼. 안정적인 그래픽카드 드라이버 만들기 아직도 더럽게 어려운 것에는 다 이유가 있죠.리눅스 커널 코드 훑어 보면 2000년대 초반에 짜져서 여지것 큰 수정 없이 사용되고 있는 부분들 엄청나게 많아요. 잘 문제없는 코드 갑자기 뜬금없이 아침에 일어나서 "그 부분에 TDD를 해보자!" 하는 개발자 없다고 봐야죠. 보안전문가가 아닌 이상.TDD 한다고 하드웨어 개발한 회사에 mock up 기기나 시뮬레이터 만들어 달라고 할 수도 없는 노릇입니다. 요즘은 가상화로 좀 가능성이 보이기는 하지만, 아직도 먼 미래 얘기임. 커널 개발자 한분 붙잡고 TDD에 대해서 어떻게 생각하냐고 물어보세요. 콧 웃음 칩니다. 뭐, 페이지 관리 코드나 파일 시스템 같이 하드웨어와 관련 없는 곳은 어느정도 가능 하겠죠. 인터럽트 걸고, critical section 걸고, RCU 하고, ring buffer, MMIO 매핑 해야하는 장치 드라이버는 꿈도 못 꿈. 그냥 코드 짜면서 테스트 해보고, 잘 되면 그냥 커밋 해요.TDD는 상위 애플리케이션 개발자들(웹, 네이티브/모바일 FE 등)의 wet dream 일 뿐이에요. TDD 할 여유 있으면 소프트웨어 품질에 확실히 좋죠. 하지만 PM이 ㅈ도 모르고 자사 제품 성격을 모르고 적용할 곳에 적용하지 않고 무작정 적용하려 한다? 그럼 다른 회사 알아봐야 한다는 신호로 받아들이시면 됨.

테스트 코드 TDD

7개의 답변

Q&A 목록