Issuu on Google+

Day 1

실습으로 배우는

테스트 주도 개발

1


학습목표  본 교육과정은 실습을 통해 TDD를 배워보는 과정입니다.  TDD 그 자체가 목적이 아니며, 효율적인 프로그래밍을 위한 과정의 하나로, 올

바른 개발 스타일을 몸에 익히는 것이 이번 교육의 목적입니다.

2 디자인패턴


Learning concept

-

Wisdom over Knowledge

-

Practice over Seeing

-

I don’t know what I don’t know

-

options and guide for good TDD 3


과정 진행 키워드: 3C

Consideration Communication Cooperation 4


Day 1

5


첫째 시간

기초점검

6


환경설정 및 기본코드 작성 개발 환경을 확인합니다.

간단한 코드를 작성해 봅니다.

7


워밍업 연습문제

0에 가까운 숫자 찾기

8


전통적인 개발 진행 문제발생

요구사항 발생 기능구현 Console 에 값 찍어보기

간단한 테스트 Yes

에러발생? No

완료! 9


일반적인 개발 1. 특정 모듈의 개발 기간이 길어질수록 개발자의 목표의식이 흐려진다. “어디까지 짰더라?” “아, 내가 지금 뭘 하는 거였지?”

“이 모듈이 무슨 기능을 해야 한대더라?” 2. 작업 분량이 늘어날수록 확인이 어려워진다.

“로그가 어디 있더라?” “이것도 화면으로 출력해보고…”

10


일반적인 개발 3. 개발자의 집중력이 필요해진다. “앗! 화면 지나갔다!” 4. 논리적인 오류를 찾기가 어렵다.

“여기서 그러니까 이 값이 들어가면 나와야 하는 게… 아… 이게 맞던가?” 5. 코드의 사용 방법과 변경 이력을 개발자의 기억력에 의존하게 되는 경우가 많다.

“맞아! 개인고객 인증을 고치면 법인 고객인증 부분도 함께 고쳤어야 했었지!!” 6. 테스트 케이스가 적혀 있는 엑셀 파일을 보며 매번 테스트를 실행하는 게 점점 귀찮아져서 는 점차 간소화하는 항목들이 늘어난다. “날짜? 1111. 주민번호? 우선 222222-2222222. 주소? 서울 개똥이네” 11


일반적인 개발 7. 코드 수정 시에 기존 코드의 정상 동작에 대한 보장이 어렵다. “휴~ 찾았다. 여길 고쳐야 하는 거였군! 아, 근데 이 금칙어 필터 모듈 혹시 다른 데서도 쓰는거 아냐?” 8. 테스트를 해보려면 소스코드에 변경을 가하는 등, 번거로운 선행 작업이 필요할 수 있다. “입고 처리를 테스트하려면, 주문이 완료됐다고 테이블에 직접 업데이트를 해줘야…” 9. 그래서 소스 변경 시 해야 하는 회귀 테스트3는 곧잘 희귀 테스트(rare test)가 되기 쉽다. “아, 그걸 언제 다 다시 테스트해? 우선 급한 불부터 끄고 보자구. 집에 안 갈거야?”

12


좋은 설계를 위한 노력,

좋은 설계자를 만들어 내기 위한 노력

13


객체 지향 기본 원칙

14


OCP SRP ISP

Demeter’s Law (=Hollywood law) IOC

15


다음 두 코드 중 더 나은 디자인은? Case.1

class Rental { Movie movie; Rental(Service service) { this.movie = service.getMovie(); } }

Case.2

class Rental { Movie movie; Rental(Movie movie) { this.movie = movie; } }


(based on my eight year s of exper ience)

St r ongly r ecommended appr oach #1

테스트 주도 개발

Test-Driven Development

17


기원 Origin

애자일(agile) 개발방식 중 하나인 XP의 실천방법 중 하나

18


TDD의 기본 “프로그램을 작성하기 전에 테스트 먼저 하라!” Test the program before you write it.

“잘 동작하는 깔끔한 코드” Clean code that works

“질문  응답  정제  반복” Ask  Respond  Refine  Repeat

19


Test Driven Development Cycle  질문 Ask : 테스트를 작성함으로써 시스템에 질문한다. (FAIL)  응답 Respond : 테스트를 통과하는 코드를 작성해서 질문에 대답한다. (PASS)  정제 Refine : 아이디어를 통합하고, 불필요한 것은 제거하고, 모호한 것은 명확히 해서 대답을 정제한다. (REFACTORING)  반복 Repeat : 다음 질문을 통해 대화를 계속 진행한다.

20


코딩 시연

21


몇 가지 설문

22


어떤 애자일 기법을 적용하고 있습니까? 관리 기법을 제외한 개발 테크닉으로만 순위를 뽑아보면 다음과 같다. 1위: 단위 테스트(Unit Testing) 2위: 지속적인 통합(Continuous Integration) 3위: 자동화된 빌드(Automated Builds) 4위: 테스트 주도 개발(TDD) 5위: 짝 프로그래밍(Pair Programming)

2009년 7월부터 12월까지 88개국 총 2570명을 대상으로 조사한 결과다. 23


70%

38%

24


가장 큰 효과를 봤던 Agile 기법 CI와 일일 스탠드업 미팅, TDD

가장 배우기 어려웠던 Agile 기법 개발/인수 TDD, 짝 프로그래밍

25


Start Test with JUnit 1. xUnit Test Frmawork 중 하나 2. Text base 혹은 GUI(Swing) base 로 구동됨 3. xUnit Style을 따른다. assert (예상값, 실제값) 4. 결과는 성공:녹색/실패:붉은색 중 하나로 표시

26


JUnit Assertions - assertEquals( [message], expected, actual) - assertTrue( [message], expected ) / assertFalse( [message], expected ) - assertNull( [message], expected ) / assertNotNull( [message], expected) - fail( [message] ) 27


Sample Practice  Account Class - 계좌 잔고 조회 - 입금/출금

- 예상 복리 이자 (추가 개발)

28


Outlook 1. 정형화된 형태의 테스트를 작성함으로써 테스트 과정을 자동화한다. 2. 테스트 결과를 즉시 알 수 있다. 3. 개발하는 시점 이후로도 지속적인 테스트가 보장되며 4. 이를 통해 전체 프로젝트의 안정성에 크게 기여한다.

5. 이러한 모든 과정이 개발자에게 짐이 되는 것이 아니라 즐거운 커뮤니케이션의 수단이 된다

29


품질 (Quality Assurance Problem)

30


품질을 어떻게 높을 것인가?

어느 정도 속도로 개발을 진행할 것인가?

31


테스트 주도 개발을 통한 품질 향상 실체화 연구

출처 : 테스트 주도 개발을 통한 품질 향상 실체화: 업계 개발팀 네 팀들에 대한 적용 결과와 경 험들 (Nachiappan Nagappan & E. Michael Maximilien & Thirumalesh Bhat & Laurie Williams) 32


단점은?

33


어려운 비교 결함발생 10% 증가

개발기간 10% 증가 선택은?

34


….

35


Be expertise 1. Experience 2. Divide & Conquer 3. Co-operation


TDD를 더 잘하고 싶다면…

XXX를 더 잘하고 싶다면…

37


잘하면 고효율, 못하면 가문의 원수가 되는

짝 프로그래밍 Effective Pair Programming

38


짝 프로그래밍 (Pair Programming) 39


Give 효율! Take 성장감!

40


결함감소율 15% ~ 50%

41


고려사항 - 개발자(설계자)의 스킬 - 업무 난이도

- 작업 시간이 더 걸릴 수 있다

42


혼자 할 때 보다

Pair Programming 으로 할 때에 업무가 더 즐거웠습니까?

출처 Factors Affecting the Perceived Effectiveness of Pair Programming in Higher Education 43


Comments 우리가 하루에 절반 이상을 쏟아 붓는 ‘일’이 재밌어 진다고 한다면, 효율을 떠나서 그것만큼 즐거울 일이 또 있을까요? 즐겁게 일하고 월급도 나온대요!!

44


혼자 할 때 보다 Pair Programming 으로 할 때에 더 많이 배웠다고 생각합니까?

45


46


짝 프로그래밍의 성공 조건

47


짝 프로그래밍은 둘이 함께 같은 업무를 개발 하는 것이다?

48


99% Fail!!


요령과 발생할 수 있는 문제점, 그리고 대처 방식을 사전에 알려주어야 함

50


네비게이터

드라이버 51


- 명시적인 역할 전환 - 오래 한 역할을 하지 않을 것!

- 둘 다 편안한 자세를 잡을 것!


고려사항 - 개발자(설계자)의 스킬 - 업무 난이도

- 작업 시간이 더 걸릴 수 있다


효율 높았던 경우 - 프로젝트 초반 - 창의성이 요하거나 어려운 업무

- 신입 팀원을 적응 시킬때


Do - 상대방에 대한 존중 - 개발 업무의 목표를 잊지 않을 것


Don’t - 짜증 - 100분 토론

Q> 짜증의 표현에는 또 어떤 것들이 있을까요?


실패 케이스들


자존심 대결


마이크로 컨트롤


문화/성별에 따른 차이


Too easy or Too Hard


성공 케이스 - 오월동주(吳越同舟) - 후배 키우기 혹은 업무 백업 - 챙겨주기는 문화 & 즐겁게 일하기

=> 좋은 팀웍!


잘되면 짝 설계까지도 도전! Simpler, More-maintainable and catch design defects early


네 번째 시간

TDD 작성패턴 TDD workshop by Pair Programming

64


TDD 작성 기본 원칙 - 실패하는 테스트를 작성하기 전에는 절대로 제품 코드를 작

성하지 않는다. - 실패하는 테스트 코드를 한 번에 하나 이상 만들지 않는다.

- 현재 실패하고 있는 테스트를 통과하기에 충분한 정도를 넘 어서는 코드는 작성하지 않는다.

65


생성자 메소드 테스트 constructor method test public class EmployeeDaoTest {

@Test public EmployeeDaoTest { EmployeeDao dao = new EmployeeDao(); assertTrue(dao.isConnected()); }

66


동치 비교 equivalence test @Test public void testEquals_case2() { Music musicA = new Music("BAD", "Michael"); Music musicB = new Music("BAD", "Michael"); assertEquals ( musicA, musicB); }

67


동치 비교 equivalence test 해결책.1

내부 상태(보통은 필드값)를 직접 꺼내와서 각각 비교한다.

해결책.2

toString을 중첩구현해(override)놓고, toString 값으로 비교한다.

해결책.3

equals 메소드를 중첩구현한다.

해결책.3

Unitils의 assertReflectionEquals를 이용한다. 68


배열 비교 array test 해결책.1

JUnit 4의 assertArrayEquals를 이용한다.

해결책.2

Unitils의 assertReflectionEquals나 assertLenientEquals를 이용한다

해결책.3

List로 변환해서 비교한다.

69


배열 비교 array test @Test public void testArrayEqual_NotSorted() { String[] arrayA = new String[] {"A", "B", "C"}; String[] arrayB = new String[] {"B", "A", "C"}; Arrays.sort (arrayA); Arrays.sort (arrayB); assertArrayEquals (arrayA, arrayB); }

70


다섯 번째 시간

짝 TDD실습 TDD workshop by Pair Programming

71


자판기 잔돈 계산 - 최소 개수의 동전으로 잔돈을 돌려준다. 예) 1000원 넣고 650원짜리 음료를 선택했다면, 잔돈은 100, 100, 100, 50 원으로 반환한다.

- 지폐를 잔돈으로 반환하는 경우는

없다고 가정한다.

72


여섯 번째 시간

TDD고급 Advanced Technic of TDD

73


Mock Object(모의 객체) 의존성을 분리하기 위해 만드는 가짜 객체

74


Mock Object 모의 객체를 사용하는 경우 - 테스트 작성을 위한 환경 구축이 어려워서 - 테스트가 특정 상황이나 순간에 의존적이라

- 테스트 시간이 오래 걸려서

75


Mock Object 테스트 더블(Test Double)

- dummy - stub - fake

- spy - Mock 76


테스트 더블 - Dummy 겨우 컴파일만 되는 바보 객체

77


테스트 더블 - Stub 특정 상태를 대표해서 동작하는 객체

78


테스트 더블 - Fake 일부 기능성 로직이 들어가 있는 객체

79


테스트 더블 - Spy 객체의 내부 상태를 기록해 주는 객체

80


테스트 더블 - Mock 객체의 내부 상태뿐 아니라 동작까지도 감시할 수 있게 만든 객체

81


실습 모의 객체를 이용한 테스트 작성

82


Mockito CreateMock 인터페이스에 해당하는 Mock 객체를 만든다.

Stub 테스트에 필요한 Mock 객체의 동작을 지정한다 (단, 필요 시에만).

Exercise 테스트 메소드 내에서 Mock 객체를 사용한다.

Verify 메소드가 예상대로 호출됐는지 검증한다.

83


Mockito

84


Q&A

85


Wrap up 우리가 놓친 점은 무엇인가?

86


Day 2 <예고> - Why we failed? - Where to start - TDD for Design, Design for TDD

- DO WRITINGS - Advanced Techniques & Pitfalls - more TDD, MORE!

87


실습으로 배우는 TDD Learn TDD by practice by @doortts

88


실습으로 배우는 TDD - day01