Skip to main content
Day02


        실습으로
 배우는
 

                                 테스트
 주도
 개발
 



                                                                                                                                                 1	
  
학습목표

u  본 교육과정은 실습을 통해 TDD를 배워보는 과정입니다.
u  TDD 그 자체가 목적이 아니며, 효율적인 프로그래밍을 위한 과정의 하나로, 올바
 른 개발 스타일을 몸에 익히는 것이 이번 교육의 목적입니다.




                                                    2	
  
                                                디자인패턴
 	
  	
  	
  	
  1. 코드개선


          1.  객체지향 특징

          2.  코드 개선 [실습]




                                  3	
  
                              디자인패턴
Learning concept


-    Wisdom over Knowledge

-    Practice over Seeing

-    I don’t know what I don’t know

-    options and guide for good TDD

                                      4
과정 진행 키워드: 3C


   Consideration
   Communication
   Cooperation

                   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;