doortts / blog star
08-02
Open
#9 9장 - 자주 접하게 되는 질문들, FAQ star
08-02 Open

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

9장 본문#

09-TDD-related-FAQ.pdf

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

Answers, Side B.#

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

  1. 저희는 이미 충분히 많은 기능 테스트를 하고 있습니다. 그런데도 따로 단위 테스트 케이스 를 만들 필요가 있을까요?
    • 이미 훌륭합니다. 뭘 더 바래요?
  2. 개발 시에 결과값을 미리 예상할 수 없는 경우에는 그럼 어떻게 TDD를 진행하나요?
    • 결과값을 미리 알 수 없는 경우는 어떤 대상에 대해 학습중이거나 외부 API를 호출하는 경우가 많은데, expected 값을 아무값이나 넣어 놓고 나중에 결과가 나왔을때 실패하는 actual 값을 복사해서 그 시점에 expected 로 맞춰서 테스트를 성공시키시는 것도 방법입니다. 전 이 방법을 종종 씁니다.
  3. 저희는 특정 객체 생성 시 사용되는 값이 랜덤 값입니다. 이런 랜덤 값에 대한 테스트는 어 떻게 만드나요?
    • 산술적 랜덤일 경우는 책에 나온대로 하시고, 논리적 불규칙성일 경우에는 contains one of them ? 으로 체크하거나 삼각 측량식으로 다른 논리값으로 비교를 하세요.
  4. 만일 팀 내에 TDD를 통한 단위 테스트 케이스를 작성하지 않고도 이미 높은 수준의 코드를 작성하고 있다면 어떻게 해야 할까요?
    • 축하드립니다. 팀 정신을 살려 계속 정진하시면 됩니다.
  5. 단위 테스트 케이스 코드를 작성하기가 여전히 어렵습니다. 옆 동료를 보니까, 전 잘 이해 할 수 없는 코드를 이용해 어떻게든 테스트 코드를 만들면서 진행하고 있던데, 저는 어떻게 해야 할까요?
    • 옆 동료를 멀리하세요. 그리고 해당 코드를 넘겨 받지 않도록 최선을 다하시길 기원합니다.
  6. 저희는 대부분의 코드를 TDD 방식으로 개발했습니다. 그리고 커버리지 100%의 자동화된 테스트도 갖고 있답니다. 자, 이젠 QA팀을 해체해도 되겠죠?
    • 어디서 지금 약을 파시는거죠? 대체 QA팀의 누가 싫은거죠?
  7. 왜 이클립스의 각종 기능과 단축키 등을 사용해야, 혹은 배워야 하나요? 전 울트라 에디터 (UltraEditor)나 심지어 때로는 메모장(notepad)으로도 충분히 잘할 수 있다구요! (게다가 TDD 랑 무슨 상관?)
    • 방문을 환영합니다! 참! 과거 몇 년도에서 오신거죠?
  8. 저희는 화면 UI가 매우 중요합니다. 그중에서 이미지 관련한 부분이 특히 중요합니다. 고정 이미지도 있고, 어도비 플래시를 이용한 움직이는 이미지도 있습니다. 이럴 경우에는 어떻게 TDD를 진행할 수 있나요?
    • 반갑습니다! 조금전에 친구분이 먼저 오신것 같던데.
    • 이미지 라이브러리나 알고리듬 개발이 아니라면 굳이 이런 UI TDD는 하지마세요.
  9. private 메소드도 테스트 케이스를 만들어야 하나요?
    • 만들면 좋구 안만들어도 뭐라고는 안할게요.
  10. 사용자가 직접 수행하는 수동 테스트와 자동화된 테스트, 굳이 TDD에 한정하지 않고 봤을 때, 어느 것이 더 중요한가요?
    • 어느게 더 중요하다기 보다는 가각 비용을 따져보시고 결정하면 되겠습니다.
  11. TDD를 적용하기 어려운 대표적인 이유는 무엇입니까?
    • 설계 지식과 경험이 먼저 어느정도 갖추어져야 좀 더 잘 할 수 있는데 그렇지 못하기 때문에 제일 큰 원인이라고 생각합니다.
  12. 이러저러한 노력에도 불구하고 TDD가 잘 안 되고 서툽니다. 어떻게 해야 하나요?
    • 하지마세요. 안잡아갑니다. 코드를 작성하고 나서 테스트를 작성해도 충분합니다.
    • 아.그럼 테스트 코드를 안만들어도 된다는 의미신거죠?
      • 아니요. 레거시프로젝트가 아니라 새로 시작하는 프로젝트라면 테스트 코드는 꼭 만드세요.
  13. 저는 SI 프로젝트 위주로 일하고 있습니다. SI에서 TDD를 적용하는 것이 바람직할까요?
    • 바람직하다라... 흠. 어렵네요. 모르겠어요.
  14. TDD는 개발 기법으로 봐야 하나요? 아니면, 테스팅 기법으로 봐야 할까요?
    • TDD는 개발 (실력 자랑) 기법으로 보시면 됩니다. (농담~ 농담~)
  15. TDD를 하면 TDD를 하지 않은 경우에 비해 확실히 품질도 좋아지고, 개발도 빨라지는 거, 맞죠?
    • 통계적으로는 그렇긴 한데, 왜인지 저에게는 통계분포 그래프상 다수 그룹 밖에 위치하는 일들이 곧잘 일어나더라구요.
  16. 테스트 케이스를 최대한 정교하게 작성하려고 노력하고 있습니다. 그런데, 그러다 보니 테 스트 대상 객체나 코드가 조금만 변경이 일어나도 테스트가 와장창 깨져서 유지보수하는 데 비용이 많이 듭니다. 이젠 솔직히 TDD에 대한 회의가 들 정도에요. 뭐가 잘못된 걸까요?
    • "제가 짠 코드는 요구사항 하나만 바뀌어도 고쳐야 하는 모듈이 여러개에요~"와 유사한 상황이라고 생각하시면 됩니다.
    • 테스트 코드도 유지보수해야 하는 개발 코드의 일부로 간주해서 지속적으로 개선해야 합니다.
  17. 면접 시에 TDD에 대해 물어보는 건 어떻게 생각하시나요?
    • 물어본 사람은 진지하게 해본적이 없거나 자랑하고 싶어서 빨리 다시 내가 말할 차례가 되었으면 좋겠다고 생각하는 상황, 둘 중 하나라고 생각합니다.
  18. 팀에 TDD를 도입하고자 할 때 초반에 TDD 외에 다른 어떤 활동을 같이 하면 좋을까요?
    • Pair Programming과 Code Review
  19. 팀에서 여전히 JDK 1.4 버전을 쓰고 있어서 짜증이 나요. JUnit 4는 저 하늘 멀리 있고요, 스프링의 최신 버전 기능도 못 쓰고, Google Guice8도 못 쓰고, 심지어 FindBugs 최신 버전 도 전혀 쓸 수가 없어요. 그런데도 이 인간들은 “꼭 Java 5를 써야 해?”라든가, “기존 시스템 이 JDK 1.4를 쓰는데 같이 쓸려면 어쩔 수 없어. 1.4 쓰자!”라고 말합니다. 제가 보기엔 다 핑 계이고요, Java 5의 신기능(맙소사! 이미 썬에서는 Java 5의 서비스 지원종료 전환기간에 돌 입했다구요!)을 공부하기 귀찮아서인 게 뻔하다구요. 정말이지 개발할 의욕이 안 난다니깐요 (JUnit 4 쓰고 싶단 말이에요). 여기까지는 넋두리고요, 이제 진짜 질문입니다. 팀에서 별로 달 가워하지 않는데도 굳이 TDD를 쓰자고 계속 주장해야 할까요?
    • 아! 친구분들 아까부터 먼저 와 계세요.
  20. 보통 이야기할 때 TDD와 단위 테스트를 혼용해서 쓰는데, 둘이 같은 거 맞죠?
    • 음. 우선 노트나 메모장을 준비하세요. 그 다음, 방금 그 말을 한 사람 이름을 잘 적어두시고 좀 더 시간을 두고 관심있게 그 분을 지켜 보시는게 좋겠습니다.
  21. 저희는 옆 팀처럼 바보같이 테스트 커버리지 100%에 도전하고 있지 않습니다. 저희 팀은 큰 부담 없이 작성할 수 있는 비율이 80%라는 걸 알고 살짝 도전적으로 85%를 목표로 잡았습 니다. 잘하고 있는 거겠죠?
    • 어느 회사입니까? 이렇게 경쟁적으로 커버리지를 높이기 위한 노력을 하다니 감동적이네요.
  22. TDD로 개발을 진행해나간다고 하면, UML은 언제 쓰나요?
    • UML 이라면 Universe Modeling Language 를 말하는거 맞죠?
  23. 전 C++ 개발자인데요, 추천할 만한 테스트 프레임워크는 없나요?

깨알#

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

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

10장 예고 #

884-20188-2-2357-53.png
꽤 괜찮은 챕터입니다.

Issue Sharer
Comment 1

    • Markdown help
    • Headers
    • Links
    • Lists
    • Images
    • Blockquotes
    • Codes
    • Tables
    • Styling
    • Short Links
    • Markdown Input
      Markdown Output
      # This is an H1
      ## This is an H2
      ### This is an H3
      
      # This is an H1 ## This is an H2 ### This is an H3
    • Markdown Input
      Markdown Output
      - Red
          1. White
          2. Blue
      - Green.
      
      - Red 1. White 2. Blue - Green
    • Markdown Input
      Markdown Output
      ![title](https://repo.yona.io/assets/images/ico-like-small.png "Yobi")
      
      ![title](/assets/images/ico-like-small.png "Yobi")
    • Markdown Input
      Markdown Output
      > Lorem ipsum dolor sit amet, consectetuer adipiscing elit.
      >
      > Aenean commodo ligula eget dolor.
      
      > Lorem ipsum dolor sit amet, consectetuer adipiscing elit. > > Aenean commodo ligula eget dolor.
    • Markdown Input
      Markdown Output
      `function test() {console.log("hello world");}`
      
      ```javascript
      function test() {
        console.log("hello world");
      }
      ```
      
      `function test() {console.log("hello world");}` ```javascript function test() { console.log("hello world"); } ```
    • Markdown Input
      Markdown Output
      | Default      | Align center | Align right |
      | ------------ | :----------: | ------: |
      | Carrot       | Red          | 1,000   |
      | Banana       | Yellow       | 32,000  |
      
      | Default | Align center | Align right | | ------------ | :----------: | ------: | | Carrot | Red | 1,000 | | Banana | Yellow | 32,000 |
    • Markdown Input
      Markdown Output
      *This is an italic*
      **This is an bold**
      ~~This is an strike~~
      
      *This is an italic* **This is an bold** ~~This is an strike~~

    통계적으로는 그렇긴 한데, 왜인지 저에게는 통계분포 그래프상 다수 그룹 밖에 위치하는 일들이 곧잘 일어나더라구요.
    테스트 코드도 유지보수해야 하는 개발 코드의 일부로 간주해서 지속적으로 개선해야 합니다.

    이 두 문장이 특히나 공감이 되네요. 특히나 실제 개발 코드보다 테스트 코드에 대한 유지보수 작업으로 인해 생산성이 저하된다고 느끼는 순간이 불쑥불쑥 올 때면... 아 아닙니다.

Add a comment
New subtask
Assignee
No assignee
Due date
No due date