Se ha denunciado esta presentación.
Utilizamos tu perfil de LinkedIn y tus datos de actividad para personalizar los anuncios y mostrarte publicidad más relevante. Puedes cambiar tus preferencias de publicidad en cualquier momento.

23

Compartir

Descargar para leer sin conexión

Test Driven Development (TDD) basic

Descargar para leer sin conexión

사내 TDD 세미나용

Simple unit-test framework:
https://github.com/Curt-Park/JWTest

Audiolibros relacionados

Gratis con una prueba de 30 días de Scribd

Ver todo

Test Driven Development (TDD) basic

  1. 1. Test-Driven Development basic Jinwoo Park, XFT-Aries, LMR PD TC3 Team
  2. 2. 2 1. Test-Driven Development? 2. By Example: Action speaks louder than words 3. By Demonstration: 실천궁행(實踐躬行) 4. TDD Basic Strategy 5. Testing Pattern 6. Refactoring 7. Design Patterns in Test Framework: JUnit 8. Retrospective.. 9. My & Your Assignment 10.Reference Contents
  3. 3. 3 › Learning how to do TDD › NO! › Learning the philosophy › YES! › So, How? › 배운것을 실천하며 체득한다! : 지행일치(知行一致) GOAL
  4. 4. 4 Test-driven development? Test-driven development › 한국어로는 테스트 주도 개발 잠시만 안녕.. › 테스트? 주도 개발? 흠.. › 단일사고적(Monological) 접근으로! › 논제를 쪼개보자. ›테스트 / 주도 개발
  5. 5. 5 Test-driven development? Test › 도와줘요! 네이버사전! › v. Test: 수작업의 느낌 › n. Test: 자동화된 느낌 › Quiz. TDD의 Test는 명사인가? 동사인가?
  6. 6. 6 Test-driven development? Automated Test › 모든 테스트 케이스를 코드 스크립트로 변환한 집합체 <MCT Test>
  7. 7. 7 Test-driven development? Why we need it? › 소프트웨어의 소스는 복잡하게 연결되어 있다.
  8. 8. 8 Test-driven development? Why we need it? › 여기서 작은 부분이 수정된다면?? 마음이 불안해진다..
  9. 9. 9 Test-driven development? Why we need it? › 모든 기능을 다시 테스트해야 한다.
  10. 10. 10 Test-driven development? Why we need it? › 또한 소스코드는 시간이 지나며 녹이 슨다.
  11. 11. 11 Test-driven development? Why we need it? › 끊임없는 리펙토링이 필요.
  12. 12. 12 Test-driven development? Why we need it? › 하지만 리펙토링이 녹록치 않다. “We are waiting for you!”
  13. 13. 13 Test-driven development? Why we need it? › 이 경우도 모든 기능을 다시 테스트 해야 한다.
  14. 14. 14 Test-driven development? No automated test? › 버그 검출 능력 저하 › 소스 코드 품질 저하 › 자체 테스트 비용의 증가
  15. 15. 15 Test-driven development? So, Test automation == TDD ?? › 그렇다면 테스트 자동화가 곧 TDD일까? Test -Driven Development 이제 헤어지지 말자.. › 생각을 확장할 때가 되었다.
  16. 16. 16 Test-driven development? Architecture-driven development › 남녀노소 익숙한 개발 주기 설계 코딩 테스트 Next Cycle › 자동화된 테스트코드의 작성이 불가능할까?
  17. 17. 17 Test-driven development? However.. › 누구나 겪어봤을 고통.. 1. 설계: 불행하게도 초반에 완벽한 설계를 하기는 힘들다. 2. 코딩: 설계가 완벽하지 않기에 코딩이 산으로 간다. 3. 테스트: 설계<->코딩 주기를 반복하며, 요구사항이 어느 정도 구현되고 나서야 작성되기 시작한다. 4. 요구사항변경 or 설계미스발견: 테스트 코드작성은 아직 미완상태. 이제 모든것이 꼬이기 시작한다.. 5. 리펙토링: 포기.
  18. 18. 18 Test-driven development? Again.. Again.. And again.. › 이런 상황이 계속되어 버리면.. 스트레스 테스트 외부변수 악영향 악영향 <Influence Diagram>
  19. 19. 19 Test-driven development? It makes uncertainty › 불확실성은 두려움을 만든다. 두려움은 우리를.. 1. 망설이게 만든다. 2. 커뮤니케이션을 덜 하게 한다. 3. 피드백 받는 것을 피하도록 한다.
  20. 20. 20 Test-driven development? So we need courage! › 용기를 얻기 위해선 어떻게 해야할까. 1. 불확실한 상태로 있는 대신, 가능하면 재빨리 구체적인 학습을 시작 한다. 2. 침묵을 지키는 대신 좀 더 분명하게 커뮤니케이션을 한다. 3. 피드백을 회피하지 말고 도움이 되는 구체적인 피드백을 찾는다.
  21. 21. 21 Test-driven development? For what? › “Clean Code that works” – Ron Jeffries › 궁극적 목표는 바로 “작동하는 깔끔한 코드”를 작성하는 것!
  22. 22. 22 Test-driven development? So.. How? › 발상의 전환! 테스트우선 스트레스 외부변수 긍정적효과 긍정적효과 <Influence Diagram>
  23. 23. 23 Test-driven development? Test drives development › 즉, 개발 주기에서 테스트 작성을 우선시한다! TestCoding “난 더이상 네 개가 아냐.”
  24. 24. 24 Test-driven development? This is Test-driven development! 테스트 실패를 확인 테스트를 통과시킨다 테스트 성공을 확인 작은 크기의 테스트작성 리펙토링 Next Cycle
  25. 25. 25 Test-driven development? What is the advantage? › 아는 것을 행할시간. › 실천을 통해 체감해본다.
  26. 26. 26 By Example Scenario › 회사가 판매하는 채권 포트폴리오 관리 시스템의 새로운 고 객이 문득 이런 요구사항을 던진다. "시스템이 제공하는 기능들에 굉장히 감탄했습니다. 헌데, 미 합중국 달러로 명명된 채권만 다루고 있더군요. 저는 새로운 채권 펀드를 시작하려고 하는데 제 전략상 다른 화폐로 채권을 다룰 필요가 있습니다.“
  27. 27. 27 By Example System implementation › 시스템이 기존에 제공했던 기능은 다음과 같을 것이다. 종목 주 가격 합계 IBM 1000 25 25000 GE 400 100 40000 합계 65000
  28. 28. 28 By Example System implementation › To-Do List를 작성해본다. To-Do List - 가격과 주를 곱해서 총 합계를 구하는 기능 : 2 * 5USD = 10USD
  29. 29. 29 By Example System implementation › 테스트 코드를 작성해본다. › 컴파일 실패! 1. 아직 Dollar 클래스가 존재하지 않는다. 2. Dollar 내부엔 int를 입력받는 생성자가 필요할 것이다. 3. Dollar 내부엔 times(int) 라는 함수가 필요할 것이다.
  30. 30. 30 By Example System implementation › 재빠르고 비열하게 코드를 작성한다. › 컴파일 성공!
  31. 31. 31 By Example System implementation › 테스트를 실행해본다. › 테스트 실패!
  32. 32. 32 By Example System implementation › 비열하게 테스트를 통과시켜보자. › 컴파일 성공!
  33. 33. 33 By Example System implementation › 비열하게 테스트를 통과시켜보자. › 테스트 성공!
  34. 34. 34 By Example System implementation › 마지막 단계! 리펙토링. › 상수로 선언된 부분을 추상화한다.
  35. 35. 35 By Example System implementation › 코드를 변경하였으니 테스트를 통과시켜보자. › 테스트 성공!
  36. 36. 36 By Example System implementation › To-Do List를 갱신한다. To-Do List - 가격과 주를 곱해서 총 합계를 구하는 기능 : 2 * 5USD = 10USD
  37. 37. 37 By Example System implementation › 시스템이 앞으로 제공해야 할 기능은 다음과 같을 것이다. 종목 주 가격 합계 IBM 1000 25USD 25000USD Novartis 400 150CHF 60000CHF 합계 65000USD ※ 환율 : 1.5CHF = 1USD
  38. 38. 38 By Example System implementation › To-Do List를 갱신한다. To-Do List - 가격과 주를 곱해서 총 합계를 구하는 기능 : 2 * 5USD = 10USD - USD와 CHF를 더해서 USD로 나타내는 기능 : 10USD + 15CHF = 20USD - 가격과 주를 곱해서 총 합계를 구하는 기능 : 2 * 5Franc = 10Franc
  39. 39. 39 By Example System implementation › 테스트 코드를 작성해본다. › 컴파일 실패! 1. 아직 Franc 클래스가 존재하지 않는다. 2. Franc 내부엔 int를 입력받는 생성자가 필요할 것이다. 3. Franc 내부엔 times(int) 라는 함수가 필요할 것이다.
  40. 40. 40 By Example System implementation › Dollar Class를 이용하여 Franc 클래스를 만든다. › 물론, 테스트는 성공한다.
  41. 41. 41 By Example System implementation › 리펙토링 단계 › Dollar클래스와 Franc 클래스 사이의 중복들이 거슬린다. › 둘을 묶을 수 있는 상위 클래스가 있다면 어떨까? › To-Do List는 항상 열려있다. To-Do List - 가격과 주를 곱해서 총 합계를 구하는 기능 : 2 * 5USD = 10USD - USD와 CHF를 더해서 USD로 나타내는 기능 : 10USD + 15CHF = 20USD - 가격과 주를 곱해서 총 합계를 구하는 기능 : 2 * 5Franc = 10Franc - Dollar와 Franc 클래스의 상위 클래스인 Money 클래스
  42. 42. 42 By Example System implementation › Money 클래스 작성.
  43. 43. 43 By Example System implementation › Dollar 클래스 변경.
  44. 44. 44 By Example System implementation › Franc 클래스 변경.
  45. 45. 45 By Example System implementation › 테스트 성공 › 이번 사이클에서는 Dollar와 Franc에 대폭 변화가 있었다. › 기존 테스트들이 Dollar와 Franc의 기능을 검증해준다! ›코드 변경에 용기가 샘솟는다!
  46. 46. 46 By Example System implementation › 리펙토링. › 중복을 제거하자 1. 생성자 중복 2. 멤버변수 중복 3. times(int) 중복
  47. 47. 47 By Example System implementation › Money: 변경이 없다.
  48. 48. 48 By Example System implementation › Dollar, Franc: 부모클래스가 제공하는 Method를 이용한다. › 테스트 통과 확인!
  49. 49. 49 By Example System implementation › To-Do List 갱신 › Dollar와 Franc의 amount가 같더라도 둘의 가치는 다르다. › Dollar와 Franc 클래스를 비교하는 기능이 필요하다. To-Do List - 가격과 주를 곱해서 총 합계를 구하는 기능 : 2 * 5USD = 10USD - USD와 CHF를 더해서 USD로 나타내는 기능 : 10USD + 15CHF = 20USD - 가격과 주를 곱해서 총 합계를 구하는 기능 : 2 * 5Franc = 10Franc - Dollar와 Franc 클래스의 상위 클래스인 Money 클래스 - Dollar와 Franc 클래스의 비교 : Dollar(5) != Franc(5)
  50. 50. 50 By Example System implementation › 테스트 코드 작성 › 컴파일 에러 › equal(Money*)함수가 존재하지 않는다.
  51. 51. 51 By Example System implementation › Money: equal(Money*)함수 구현
  52. 52. 52 By Example System implementation › 테스트 실패 › 환율에 대한 고려가 전혀 없다.
  53. 53. 53 By Example System implementation › 테스트를 통과하려면? (전략수립) 1. Dollar와 Franc에서 각각의 통화가 무엇인지 기억한다. 2. 객체간 비교시, 각 개체의 통화정보를 기준으로 USD로 변 경한 후 비교를 수행한다. 3. 환율정보를 갖고 있는 ‘무언가’가 필요하다. 4. ‘무언가’의 이름으로는 Bank가 적절할 것 같다.
  54. 54. 54 By Example System implementation › 다시 테스트 코드 작성 › 컴파일 에러 › Bank 클래스가 존재하지 않는다 › equal(Bank, Money*)함수의 입력형태가 이전과 다르다
  55. 55. 55 By Example System implementation › Bank Class 작성1 › 각 화폐는 addRate시, 자신이 갖고있는 currency 식별자를 입력할 것이다.
  56. 56. 56 By Example System implementation › Bank Class 작성2
  57. 57. 57 By Example System implementation › Money Class: 화폐 식별자 currency 추가
  58. 58. 58 By Example System implementation › Money Class: equal(Bank, Money*) 변경 › Bank에서 얻은 환율정보로 모든 화폐를 USD로 변경한다.
  59. 59. 59 By Example System implementation › Dollar Class, Franc Class 작성 › 각 화폐 생성시 자신의 식별자가 setting된다.
  60. 60. 60 By Example System implementation › 또 다시 테스트 실패 › 테스트 케이스에서 환율에 대한 정보를 입력하지 않았다. › bank.addRate(“USD”, 1.0); //추가 › bank.addRate(“CHF”, 1.0); //추가
  61. 61. 61 By Example System implementation › 테스트가 통과하는 것을 확인
  62. 62. 62 By Example System implementation › To-Do List 갱신 › 드디어 서로 다른 통화간의 합이 남았다 To-Do List - 가격과 주를 곱해서 총 합계를 구하는 기능 : 2 * 5USD = 10USD - USD와 CHF를 더해서 USD로 나타내는 기능 : 10USD + 15CHF = 20USD - 가격과 주를 곱해서 총 합계를 구하는 기능 : 2 * 5Franc = 10Franc - Dollar와 Franc 클래스의 상위 클래스인 Money 클래스 - Dollar와 Franc 클래스의 비교 : Dollar(5) != Franc(5)
  63. 63. 63 By Example System implementation › 테스트 코드 작성 › 컴파일에러! › Money에 add(Bank, Money*, string)가 추가되어야 한다.
  64. 64. 64 By Example System implementation › Money Class: add 함수 작성 › Money에 통화단위를 입력받는 생성자가 필요하다.
  65. 65. 65 By Example System implementation › Money Class: 생성자 작성 › 이로써 모든 테스트가 통과했다. › 예외처리, 리펙토링 등은 분량상 생략.
  66. 66. 66 By Example System implementation › To-Do List 갱신 To-Do List - 가격과 주를 곱해서 총 합계를 구하는 기능 : 2 * 5USD = 10USD - USD와 CHF를 더해서 USD로 나타내는 기능 : 10USD + 15CHF = 20USD - 가격과 주를 곱해서 총 합계를 구하는 기능 : 2 * 5Franc = 10Franc - Dollar와 Franc 클래스의 상위 클래스인 Money 클래스 - Dollar와 Franc 클래스의 비교 : Dollar(5) != Franc(5)
  67. 67. 67 By Example Does it make a sense? › 머리가 복잡하시죠?
  68. 68. 68 By Example Does it make a sense? › 방금 본 것은 잠시 잊으셔도 좋습니다. ›더 쉬운 예제로! ›눈 앞에서 직접!
  69. 69. 69 By Demonstration Fibonacci series
  70. 70. 70 TDD basic strategy Independent test › 각 테스트는 독립성이 보장되어야 한다. › 테스트는 충분히 빨라야한다. Q. 테스트의 독립성을 위해 Test마다 시스템을 재가동 한다면 ? Q. 재빠른 테스트를 위해 한 가지 Test 내에서 두 가지 이상의 기능을 검증한다면? › 잘만 지키면, 설계 응집도는 상승하고 결합도는 낮아진다.
  71. 71. 71 TDD basic strategy To-do list › 적는 습관을 들인다! › TO-DO LIST는 카테고리 별로 잘 정리한다! -> 규모, 우선순위 등등 › 머릿속에만 의지하게 되면.. 1. 경험이 축적될수록 TO-DO LIST가 많아진다. 2. LIST가 많을 수록 집중도가 떨어진다. 3. 집중도가 떨어지면 실수가 발생한다.
  72. 72. 72 TDD basic strategy Bottom-Up? Top-down? › 간단한 한가지 사례를 나타내는 테스트에서 시작했다면? -> Top-Down 식 구현. › 전체의 작은 한 조각에 해당하는 테스트에서 시작했다면? -> Bottom-UP 식 구현. › 즉, TDD는 상향 또는 하향에 종속된 개념이 아니다. ‘Known-to-unknown’
  73. 73. 73 TDD basic strategy Assert first › Test를 작성시 Assert를 제일 먼저 쓰고 시작하라. › 시스템의 주요한 요구사항을 극도로 추상화 시킬 수 있다.
  74. 74. 74 Testing pattern Mock object › 서버에 대한 테스트가 필요한데, 클라이언트가 없을 경우, › 원격서버와의 통신중 물리환경에 의해 테스트가 실패될 때, › 테스트 중 상대 객체에 대한 호출내역이 궁금할 때, 모의객체 (Mock Object)로 원하는 상황을 연출가능!
  75. 75. 75 Testing pattern Crash test dummy › 에러 상황에 대해 테스트할 때 사용 › 객체 전체를 흉내내지 않는 점을 제외하면 Mock Object와 유 사. › EX) 파일 시스템에 여유공간이 없는 상황을 연출하고 싶을 때.
  76. 76. 76 Testing pattern Crash test dummy Private class FullFile extends File { public FullFile(String path) { super(path); } public boolean createNewFile() throws IOException { throw new IOException(); } }
  77. 77. 77 Testing pattern Crash test dummy public void testFileSystemError(){ File f = new FullFile(“foo”); try{ saveAs(f); fail(); // 예외처리에 실패하면 테스트가 종료 } catch(IOException e) { // Do Something } }
  78. 78. 78 Refactoring Main idea › 중복을 제거한다. › 구체화 -> 추상화시킨다. › 과도한 제어흐름은 단순화 시킨다.
  79. 79. 79 Design patterns in junit xunit? › xUnit 은 스몰토크4의 테스트 프레임워크 SUnit 의 구조와 함 수들을 따라한 유닛 테스팅 프레임워크들을 총칭. › 첫 글자는 사용하는 언어에서 따온다. › 즉, JUnit은 자바를 위한 테스트 프레임워크다.
  80. 80. 80 Design patterns in junit Junit patterns summary
  81. 81. 81 Retrospective Through TDD? › 짧은 사이클의 반복으로 설계 방향을 누차 재점검 할 수 있다. 변화가 빨리 도입되는 극한적 상황에서 유리하다. › 커뮤니케이션의 용이해진다. 테스트 코드는 곧 작업에 대한 history이기도 하다. › 한참 뒤에 들이닥치는 변동사항에도 끄떡없다.
  82. 82. 82 Retrospective Once again, TDD? › TDD는 테스팅 기술이 아니다. 분석 기술이며, 설계기술이기도 하다. › 또한 개발의 모든 활동을 구조화하는 기술이다. FOR Clean code that works
  83. 83. 83 My & your assignment What else? › 실제로 해보기! 많이! › 읽어보기: TDD is dead long live testing by DHH › 시청하기: 유닛테스트의 효용성 by 김포프 › TDD에 대한 ‘나’의 입장 정리해보기.
  84. 84. 84 [1] Test Driven Development: By Examples, Kent Beck [2] 테스트 주도 개발 (Test-Driven Development), 박상준 [3] 테스트 자동화와 TDD, 박경훈 [4] JUnit A Cook's Tour [5] Java Reflection API, stackoverflow [6] Design Patterns, Programcreek [7] Extreme Programming, Wikipedia [8] TDD는 죽었다, DHH, 이상욱 역 [9] C++ 유닛테스트, 김포프 references
  • byoungchaekim

    Feb. 21, 2019
  • nicewook

    May. 19, 2018
  • YoungJaeKwon3

    Mar. 28, 2018
  • ssusere729fd

    Mar. 5, 2018
  • chaeya

    Mar. 4, 2018
  • YunhoMaeng

    Mar. 4, 2018
  • wall72

    Mar. 4, 2018
  • kyong99

    Mar. 4, 2018
  • ssuserc6b46d

    Mar. 4, 2018
  • Synch3D

    Mar. 3, 2018
  • xxxxxxxxxxxxxxxxxxxxmail

    Mar. 2, 2018
  • na6858

    Mar. 1, 2018
  • ssuser6c319d

    Feb. 26, 2018
  • jephrix

    Feb. 26, 2018
  • ssuserc7e1d71

    Feb. 26, 2018
  • onlybalance

    Feb. 26, 2018
  • juancarlosmartinez191

    Feb. 25, 2018
  • ssuserf2cb68

    Feb. 25, 2018
  • nlife00hcjung

    Feb. 25, 2018
  • RafsanMahmud1

    Feb. 25, 2018

사내 TDD 세미나용 Simple unit-test framework: https://github.com/Curt-Park/JWTest

Vistas

Total de vistas

2.517

En Slideshare

0

De embebidos

0

Número de embebidos

24

Acciones

Descargas

56

Compartidos

0

Comentarios

0

Me gusta

23

×