00009 20180802 9장 자주 접하게 되는 질문들 FAQ

number: 9
id: 2975
title: '9장 - 자주 접하게 되는 질문들, FAQ'
type: ISSUE_POST
author:
  loginId: doortts
  name: doortts
  email: [email protected]
createdAt: '2018-08-02T23:58:55+0900'
updatedAt: '2020-02-05T12:58:28+0900'
owner: doortts
projectName: blog
state: OPEN
labels:
  - labelName: TDD 실천법과 도구
    labelColor: '#00bcd4'
    category: 기술
refUrl: 'https://repo.yona.io/doortts/blog/issue/9'
attachments:
  - id: 4376
    name: 09-TDD-related-FAQ.pdf
    hash: 456712a56db770a47a3f38d9da88c1f7db981104e936ba92356e555c1d1a1f80
    containerType: ISSUE_POST
    mimeType: application/pdf
    size: 1731938
    containerId: '2975'
    createdDate: 1533218085000
    ownerLoginId: doortts
  - id: 4383
    name: 884-20188-2-2357-53.png
    hash: 7df8534725ce43d18527e40531b139bf4f446e634ee6c81fae3b648c44668960
    containerType: ISSUE_POST
    mimeType: image/png
    size: 497802
    containerId: '2975'
    createdDate: 1533221791000
    ownerLoginId: doortts
comments:
  - id: 4417
    author:
      loginId: kiravspace
      name: kiravspace
      email: [email protected]
    createdAt: '2018-08-07T10:05:54+0900'
    body: "`통계적으로는 그렇긴 한데, 왜인지 저에게는 통계분포 그래프상 다수 그룹 밖에 위치하는 일들이 곧잘 일어나더라구요.`\r\n`테스트 코드도 유지보수해야 하는 개발 코드의 일부로 간주해서 지속적으로 개선해야 합니다.`\r\n\r\n이 두 문장이 특히나 공감이 되네요. 특히나 실제 개발 코드보다 테스트 코드에 대한 유지보수 작업으로 인해 생산성이 저하된다고 느끼는 순간이 불쑥불쑥 올 때면... 아 아닙니다."

이전: 8장 - TDD에 대한 다양한 시각 다음: 10장 - 실습 예제

9장 본문

09-TDD-related-FAQ.pdf

안내: 본문을 읽지 않고 아래의 코멘터리만 읽는 걸 가정해서 작성하진 않았습니다.

Answers, Side B.

다음 내용들은 기존 책에 적힌 내용이 틀려서가 아니라 다른 시각의 의견이라고 생각하고 읽어주세요. 일부는 농담입니다.

저희는 이미 충분히 많은 기능 테스트를 하고 있습니다. 그런데도 따로 단위 테스트 케이스 를 만들 필요가 있을까요?

이미 훌륭합니다. 뭘 더 바래요?

개발 시에 결과값을 미리 예상할 수 없는 경우에는 그럼 어떻게 TDD를 진행하나요?

결과값을 미리 알 수 없는 경우는 어떤 대상에 대해 학습중이거나 외부 API를 호출하는 경우가 많은데, expected 값을 아무값이나 넣어 놓고 나중에 결과가 나왔을때 실패하는 actual 값을 복사해서 그 시점에 expected 로 맞춰서 테스트를 성공시키시는 것도 방법입니다. 전 이 방법을 종종 씁니다.

저희는 특정 객체 생성 시 사용되는 값이 랜덤 값입니다. 이런 랜덤 값에 대한 테스트는 어 떻게 만드나요?

산술적 랜덤일 경우는 책에 나온대로 하시고, 논리적 불규칙성일 경우에는 contains one of them ? 으로 체크하거나 삼각 측량식으로 다른 논리값으로 비교를 하세요.

만일 팀 내에 TDD를 통한 단위 테스트 케이스를 작성하지 않고도 이미 높은 수준의 코드를 작성하고 있다면 어떻게 해야 할까요?

축하드립니다. 팀 정신을 살려 계속 정진하시면 됩니다.

단위 테스트 케이스 코드를 작성하기가 여전히 어렵습니다. 옆 동료를 보니까, 전 잘 이해 할 수 없는 코드를 이용해 어떻게든 테스트 코드를 만들면서 진행하고 있던데, 저는 어떻게 해야 할까요?

옆 동료를 멀리하세요. 그리고 해당 코드를 넘겨 받지 않도록 최선을 다하시길 기원합니다.

저희는 대부분의 코드를 TDD 방식으로 개발했습니다. 그리고 커버리지 100%의 자동화된 테스트도 갖고 있답니다. 자, 이젠 QA팀을 해체해도 되겠죠?

어디서 지금 약을 파시는거죠? 대체 QA팀의 누가 싫은거죠?

왜 이클립스의 각종 기능과 단축키 등을 사용해야, 혹은 배워야 하나요? 전 울트라 에디터 (UltraEditor)나 심지어 때로는 메모장(notepad)으로도 충분히 잘할 수 있다구요! (게다가 TDD 랑 무슨 상관?)

방문을 환영합니다! 참! 과거 몇 년도에서 오신거죠?

저희는 화면 UI가 매우 중요합니다. 그중에서 이미지 관련한 부분이 특히 중요합니다. 고정 이미지도 있고, 어도비 플래시를 이용한 움직이는 이미지도 있습니다. 이럴 경우에는 어떻게 TDD를 진행할 수 있나요?

반갑습니다! 조금전에 친구분이 먼저 오신것 같던데.
이미지 라이브러리나 알고리듬 개발이 아니라면 굳이 이런 UI TDD는 하지마세요.

private 메소드도 테스트 케이스를 만들어야 하나요?

만들면 좋구 안만들어도 뭐라고는 안할게요.

사용자가 직접 수행하는 수동 테스트와 자동화된 테스트, 굳이 TDD에 한정하지 않고 봤을 때, 어느 것이 더 중요한가요?

어느게 더 중요하다기 보다는 가각 비용을 따져보시고 결정하면 되겠습니다.

TDD를 적용하기 어려운 대표적인 이유는 무엇입니까?

설계 지식과 경험이 먼저 어느정도 갖추어져야 좀 더 잘 할 수 있는데 그렇지 못하기 때문에 제일 큰 원인이라고 생각합니다.

이러저러한 노력에도 불구하고 TDD가 잘 안 되고 서툽니다. 어떻게 해야 하나요?

하지마세요. 안잡아갑니다. 코드를 작성하고 나서 테스트를 작성해도 충분합니다.
아.그럼 테스트 코드를 안만들어도 된다는 의미신거죠?
- 아니요. 레거시프로젝트가 아니라 새로 시작하는 프로젝트라면 테스트 코드는 꼭 만드세요.

저는 SI 프로젝트 위주로 일하고 있습니다. SI에서 TDD를 적용하는 것이 바람직할까요?

바람직하다라... 흠. 어렵네요. 모르겠어요.

TDD는 개발 기법으로 봐야 하나요? 아니면, 테스팅 기법으로 봐야 할까요?

TDD는 개발 (실력 자랑) 기법으로 보시면 됩니다. (농담~ 농담~)

TDD를 하면 TDD를 하지 않은 경우에 비해 확실히 품질도 좋아지고, 개발도 빨라지는 거, 맞죠?

통계적으로는 그렇긴 한데, 왜인지 저에게는 통계분포 그래프상 다수 그룹 밖에 위치하는 일들이 곧잘 일어나더라구요.

테스트 케이스를 최대한 정교하게 작성하려고 노력하고 있습니다. 그런데, 그러다 보니 테 스트 대상 객체나 코드가 조금만 변경이 일어나도 테스트가 와장창 깨져서 유지보수하는 데 비용이 많이 듭니다. 이젠 솔직히 TDD에 대한 회의가 들 정도에요. 뭐가 잘못된 걸까요?

"제가 짠 코드는 요구사항 하나만 바뀌어도 고쳐야 하는 모듈이 여러개에요~"와 유사한 상황이라고 생각하시면 됩니다.
테스트 코드도 유지보수해야 하는 개발 코드의 일부로 간주해서 지속적으로 개선해야 합니다.

면접 시에 TDD에 대해 물어보는 건 어떻게 생각하시나요?

물어본 사람은 진지하게 해본적이 없거나 자랑하고 싶어서 빨리 다시 내가 말할 차례가 되었으면 좋겠다고 생각하는 상황, 둘 중 하나라고 생각합니다.

팀에 TDD를 도입하고자 할 때 초반에 TDD 외에 다른 어떤 활동을 같이 하면 좋을까요?

Pair Programming과 Code Review

팀에서 여전히 JDK 1.4 버전을 쓰고 있어서 짜증이 나요. JUnit 4는 저 하늘 멀리 있고요, 스프링의 최신 버전 기능도 못 쓰고, Google Guice8도 못 쓰고, 심지어 FindBugs 최신 버전 도 전혀 쓸 수가 없어요. 그런데도 이 인간들은 “꼭 Java 5를 써야 해?”라든가, “기존 시스템 이 JDK 1.4를 쓰는데 같이 쓸려면 어쩔 수 없어. 1.4 쓰자!”라고 말합니다. 제가 보기엔 다 핑 계이고요, Java 5의 신기능(맙소사! 이미 썬에서는 Java 5의 서비스 지원종료 전환기간에 돌 입했다구요!)을 공부하기 귀찮아서인 게 뻔하다구요. 정말이지 개발할 의욕이 안 난다니깐요 (JUnit 4 쓰고 싶단 말이에요). 여기까지는 넋두리고요, 이제 진짜 질문입니다. 팀에서 별로 달 가워하지 않는데도 굳이 TDD를 쓰자고 계속 주장해야 할까요?

아! 친구분들 아까부터 먼저 와 계세요.

보통 이야기할 때 TDD와 단위 테스트를 혼용해서 쓰는데, 둘이 같은 거 맞죠?

음. 우선 노트나 메모장을 준비하세요. 그 다음, 방금 그 말을 한 사람 이름을 잘 적어두시고 좀 더 시간을 두고 관심있게 그 분을 지켜 보시는게 좋겠습니다.

저희는 옆 팀처럼 바보같이 테스트 커버리지 100%에 도전하고 있지 않습니다. 저희 팀은 큰 부담 없이 작성할 수 있는 비율이 80%라는 걸 알고 살짝 도전적으로 85%를 목표로 잡았습 니다. 잘하고 있는 거겠죠?

어느 회사입니까? 이렇게 경쟁적으로 커버리지를 높이기 위한 노력을 하다니 감동적이네요.

TDD로 개발을 진행해나간다고 하면, UML은 언제 쓰나요?

UML 이라면 Universe Modeling Language 를 말하는거 맞죠?

전 C++ 개발자인데요, 추천할 만한 테스트 프레임워크는 없나요?

C++ 월드에 들어가실 예정이시라면 요즘엔 Catch나 Boost.Test 나 Google Test 3파전입니다.

깨알

“우물쭈물하다가 내 이럴 줄 알았다.” - 버나드 쇼(George Bernard Shaw)의 묘비명에서 발췌

원래는 그렇게 남기진 않았다고 하네요.

10장 예고

꽤 괜찮은 챕터입니다.

00009 20180802 9장 자주 접하게 되는 질문들 FAQ - doortts/blog GitHub Wiki

9장 본문

Answers, Side B.

깨알

10장 예고

⚠️ GitHub.com Fallback ⚠️

00009 20180802 9장 자주 접하게 되는 질문들 FAQ - doortts/blog GitHub Wiki

9장 본문

Answers, Side B.

깨알

10장 예고

⚠️ **GitHub.com Fallback** ⚠️

⚠️ GitHub.com Fallback ⚠️