기다렸던 사람들이 많았을 것 같다. 이제야, 오늘에야 Spring 3.0.0 RC1이 나왔으니까 말이다. 물론 Toby(일민)이를 비롯한 몇몇 선행적인 개발자들이 이미 열심히 공부하고 있고, 이의 전달도 열심인 것에 비하면, 최근에 나는 크게 관심을 두려고 노력하지 않았다. 개인적으로는 다른 사업부로 옮겨와서, 새로운 일을 맡아서 관심이 적어진(?) 것도 있지만, 사실은 그것 보다도, 기존에 내가 만든 Framework는 스프링 2.5.5 또는 2.5.6을 기반으로 설계되어 있다. 그리고 이것을 이용하여 여러 솔루션들이 개발되고 있는 중이어서, 자체 개발한 Framework의 Minor 체인지가 아닌 Big 체인지를 결정하기 쉽지 않기 때문이다. 만약 그것을 결정해야 한다고 해도 2년 후가 될 것이다. (상품으로 그리고 서비스를 하고 있는 시스템을 변경하기란 많은 결정해야할 문제에 직면해야 하는 용기가 필요한다. 그러나 이것은 모험이 아니다.)

현재 Springframework에서 제공하고 있는 메이져 Branch는 2가지이지만 앞으로는 3가지가 될 것이다.
Springframework 1.2 와 2.5 그리고 향후 주축이될 3.0이다.
그리고 이제는 3.0 Release Candidate 1이 나왔다. 이제는 또 열심히 공부할 시점이 된 것이다.
여러가지 변경된 API라이브러리들도 있고, 추가된 라이브러리들이 있는데, 이중에서 가장 먼저 눈에 들어왔던 것은 Jackson JSON라이브러리이다. 이른 아침에 Jackson 투터리얼을 보면서 시간 가는줄 몰랐다.
앞으로 정식 버전이 나올날이 멀지 않았지만, 언제가 될지는 잘 모르겠다. 올해 안에는 나오지 않을지...

Springframework 3.0 RC1의 변경 사항은 다음의 링크를 보면된다.

그리고, 아래는 이번에 RC1에 추가된 내용이다.

Changes in version 3.0.0.RC1 (2009-09-25)
-----------------------------------------

* upgraded to CGLIB 2.2, AspectJ 1.6.5, Groovy 1.6.3, EHCache 1.6.2, JUnit 4.7, TestNG 5.10
* introduced early support for JSR-330 "javax.inject" annotations (for autowiring)
* introduced early support for JSR-303 Bean Validation (setup and MVC integration)
* added default editors for "java.util.Currency" and "java.util.TimeZone"
* refined PathMatchingResourcePatternResolver's treatment of non-readable directories
* PathMatchingResourcePatternResolver understands VFS resources (i.e. works on JBoss 5.x)
* revised AccessControlContext access from BeanFactory
* AbstractBeanDefinitionParser can deal with null return value as well
* PropertyOverrideConfigurer's "ignoreInvalidKeys" ignores invalid property names as well
* PropertyPlaceholderConfigurer supports "${myKey:myDefaultValue}" defaulting syntax
* BeanFactory's default type conversion falls back to String constructor on target type
* BeanFactory tries to create unknown collection implementation types via default constructor
* BeanFactory supports ObjectFactory as a dependency type for @Autowired and @Value
* BeanFactory supports JSR-330 Provider interface as a dependency type for @Inject
* BeanFactory prefers local primary bean to primary bean in parent factory
* protected @Autowired method can be overridden with non-annotated method to suppress injection
* private @Autowired methods with same signature will be called individually across a hierarchy
* @PostConstruct processed top-down (base class first); @PreDestroy bottom-up (subclass first)
* ConfigurationClassPostProcessor detect @Bean methods on registered plain bean classes as well
* support for default "conversionService" bean in an ApplicationContext
* MBeanServerFactoryBean returns JDK 1.5 platform MBeanServer for agent id "" (empty String)
* changed NamedParameter/SimpleJdbcOperations parameter signatures to accept any Map value type
* refined logging in JMS SingleConnectionFactory and DefaultMessageListenerContainer
* introduced "ui.format" package as an alternative to PropertyEditors for data binding
* @RequestMapping annotation now supported for annotated interfaces (and JDK proxies) as well
* @RequestParam and co support placeholders and expressions in their defaultValue attributes
* @Value expressions supported as MVC handler method arguments as well (against request scope)
* JSR-303 support for validation of @MVC handler method arguments driven by @Valid annotations
* refined response handling for @ExceptionHandler methods
* @ResponseStatus usage in handler methods detected by RedirectView
* all @SessionAttributes get exposed to the model before handler method execution
* @Event/ResourceMapping uniquely mapped to through event/resource id, even across controllers
* MultipartRequest is available as a mixin interface on (Native)WebRequest as well
* removed outdated "cacheJspExpressions" feature from ExpressionEvaluationUtils
* introduced common ErrorHandler strategy, supported by message listener container
* Jpa/JdoTransactionManager passes resolved timeout into Jpa/JdoDialect's beginTransaction
* HibernateJpaDialect applies timeout onto native Hibernate Transaction before begin call
* Spring's Hibernate support is now compatible with Hibernate 3.5 beta 1 as well
* Spring's JPA support is now fully compatible with JPA 2.0 as in EclipseLink 2.0.0.M7
* SpringJUnit4ClassRunner is now compatible with JUnit 4.5, 4.6, and 4.7
* SpringJUnit4ClassRunner once again supports collective timeouts for repeated tests
* deprecated @NotTransactional annotation for test classes in favor of @BeforeTransaction








Posted by 행복상자
오늘은 최근 며칠전에 보아 두었던, Twitter4J 의 API와 이를 Java에서 사용가능하도록 구현한 Twitter4J 를 분석하기로 마음 먹었다. 일단 웹에서 Twitte4J 2.0.8버전을 다운로드 받아서, Eclipse에서 환경을 만들어보았다. 다운로드 받은 파일을 압축을 풀면, Source Code와 Sample Code 그리고 Junit 코드가 있다.
Junit 코드는 Twitter4J 라이브러리의 사용법을 손쉽게 익힐수 있는 좋은 예제이다.

몇가지 테스트를 하다보니, 클라스의 메소드들의 내용을 출력해서 볼 필요가 있어서, 이를 Console에 찍어보았는데, 메소드 또는 getter를 통해서 Twitter 서버의 결과들을 가져와 그 내용을 살펴 볼수 있었다.

아래과 같이 Java Doc에 있는 문서를 뒤져서, System.out.println() 메소드를 이용하여 처음에 만들어 보았다.  
public void testSearch() throws TwitterException
 {
        Twitter tw = new Twitter();
        String queryStr = "happyzoo";
        Query query = new Query(queryStr);
        QueryResult queryResult = tw.search(query);
     
        List<Tweet> tweets = queryResult.getTweets();
        System.out.println("tweets.size: ==> " + tweets.size());
               
        for (Tweet tweet : tweets) {
         System.out.println("tweet.getText: ==> " + tweet.getText());
       System.out.println("tweet.getSource: ==> " + tweet.getSource());
                    ....    
        }
 }



위의 코드는 Junit을 이용하여 테스트용으로 만든 코드이지만, 코드의 내용을 검증하지는 않았다. 개인적으로는 TDD를 선호하지만, 갑작스럽게 확인하거나 할때는 그냥 junit에다 테스트 코드를 작성하고, 나중에 Refactoring을 한다. 새로운 Library를 익혀야 하거나 테스트 코드를 짜볼 때는 Junit로 테스트를 작성하고, 나주에 필요할 때, 다시 이를 보고, 사용법을 익히는 시간을 줄이곤 한다.

그리고, 사실 다음 단계들이 Refacoring을 하는 단계라고 생각할 수도 있다.
위의 코드가 그리 보기 않좋았다. 그래서 이를 다시 수정하였다. 나중에 코드를 작성할때 필요한 내용들을 확인할 때 재 사용이 가능할 거라고 생각하였다. (이 역시 나의 습관인데, 별도의 클래스의 작성 필요 없는 경우는 static으로 메소드를 선언하여 사용하곤 한다.)


private static void showTweet(Tweet tweet){
    StringBuffer showData = new StringBuffer();
    
    showData.append("tweet.getCreatedAt():" + tweet.getCreatedAt() + "\n");
    showData.append("tweet.getFromUser():" + tweet.getFromUser() + "\n");
    showData.append("tweet.getFromUserId():" + tweet.getFromUserId() + "\n");
    showData.append("tweet.getId():" + tweet.getId() + "\n");
    showData.append("tweet.getIsoLanguageCode():" + tweet.getIsoLanguageCode() + "\n");
    showData.append("tweet.getProfileImageUrl():" + tweet.getProfileImageUrl() + "\n");
    showData.append("tweet.getSource():" + tweet.getSource() + "\n");
    showData.append("tweet.getText():" + tweet.getText() + "\n");
    showData.append("tweet.getToUser():" + tweet.getToUser() + "\n");
    showData.append("tweet.getToUserId():" + tweet.getToUserId() + "\n");

  
    System.out.println("showData: " + showData);
 }

위 처럼 코드를 만들고 나서는, 다른 클래스에 대한 값들을 또한 확인해야 할 필요가 느껴졌다.
그런데, 위와 같은 "showData.append("... ")" 라고 일일이 쳐 주어야 하는 것이 비 생산적이라는 생각이 들어서, 자동으로 위와 같은 형태로 생성해 주면, 이를 출련한 후에 실제 코드에서 생성해서 붙여 쓰는 것이 더 생산적일 거라는 생각이 들어서, 코드를 만들어 주는 코드를 아래 처럼 짜써 넣었다.

public void createTempletCode()
 {
String[] methods = new String[]{
"getCreatedAt",
"getFromUser",
"getFromUserId",
"getId",
"getIsoLanguageCode",
"getProfileImageUrl",
"getSource",
"getText",
"getToUser",
"getToUserId"
  };
  
String str = "";
for (String method : methods) {
str += "showData.append(\"tweet." + buffer + "():\" + " + "tweet." + method + "() + \"\\n\");\n";
}
  
System.out.println(str);
 }

위의 코드는 실제 코드를 만들때의 노가다를 상단부분 없애 주었다. 물로 1~2를 위해서 쓴다면, 여기까지 만든 노력이 별로 효과가 없지만, 말이다. 하지만, 역시 단점이 있다, 메소드들을 java Doc을 뒤져서 복사해서 배열로 만들어 줘야 한다. 이 역시 적지 않은 노가다가 든다. Copy & Paste를 한다해도 메소드가 많다면, 이 역시 쉬운 작업을 아니다.

역시 한번더 개선을 해야 겠다. 일단 위의 코드를 아래처럼 별도이 메소드로 만들어 주었다.

 public static String createTempletCode(String[] methods, String instanceName)
 {
String temp = "";
for (String method : methods) {
   temp += "showData.append(\"" + instanceName + "." + method + "():\" + " + "tweet." + method + "() + \"\\n\");\n";
  }
   
  return temp ;
 }

그리고, reflection을 이용하기로 했다. 이는 junit과 AspetJ 또는 AOP에서 많이 사용되고 있고, 실제로 윈도우나 Java에서 최근들어 많이 사용되고 있는 방법이다. 그러나 사실 일반적인 개발시는 많이 이용하지 않고 있다. 그러나 나는 오는 나의 노가다를 쫑 내기 위해서, 이를 이용할 수 밖에 없었다.

"java.lang.reflect.Method"를 이용해서 내가 java Doc에서 가져오던 내용들을 한번에 가져오기로 하고 다음과 같이 수정하였다. 만약 제대로 가져오면, 위에 있는 메서드를 이용하여 쉽게 원하는 것을 출력할 수 있을 것이다.
 
public void createTempletCode()
 {
System.out.println(createTempletCode(getMethodOfClass(Tweet.class), "tweet")); 
 }

public static String createTempletCode(String[] methods, String instanceName)
 {
String temp = "";
for (String method : methods) {
 temp += "showData.append(\"" + instanceName + "." + method + "():\" + " + "tweet." + method + "() + \"\\n\");\n";
  }
   
  return temp ;
 }

public static String[] getMethodOfClass(Class clazz)
 {
  Class thisClass = clazz;
  Method[] methods = thisClass.getDeclaredMethods();
  
  String[] methodNames = new String[methods.length];
  
  for(int i =0; i < methods.length; i++ )
  {
methodNames[i] = methods[i].getName();
   
  }
  
  return methodNames;

}


코드가 많이 단순해 졌다. 처음 생각했던 내용들이 시간의 흐름사이에서, 생각도 변화하고 아이디어도 변화해서, 위와 같은 모습이 되었다.
조금 전까지도, 어차피 reflection을 적용했으니까, 생성한 코드를 바로 실행하는 로직을 만들어 넣을까도 생각했지만, 이거는 오버스펙이 될거라는 생각에 오늘은 더 이상 추가하지 않을 계획이다. 아직도 몇가지 코드들은 refectoring을 기다리고 있으니 말이다.

Twitter4J의 클래스와 메소드들은 생각보다 사용하기 쉽고, 단순하다.그리고, 이는 일본사람이 만들어서 인지 Unicode에 대한 문제도 없어 보인다.

오늘은 별다른 래퍼 클래스를 만들지 않고, 몇가지 테스트만 더하고, 내가 원하는 것을 한번 만들어 볼 생각이다.


Posted by 행복상자
내가 Unit 테스트를 위한 툴과 TDD(Test Driven development)를 공부하기 시작한 것은 2002년 부터이다.
내가 살아가면서 감사하게 생각하는 것은 내 주변에 좋은 개발자들이 있고, 이 들로 부터 개발을 위한 좋은 정보를 얻을 수 있었다는 것이다. TDD는 지금은 iPhone Application을 개발하는 연승훈이라는 분을 통해서 그 당시에 처음 접하게 되었다.  

TDD에 관한 책은 김창준, 강규영  두분의 번역으로 국내에 책이 출판되었는데, 이전에 내 블로그에 "Kent Beck의 Test-Driven Development by Example"라는 제목으로 언급하기도 했던 책으로, 이 책은 내가 프로젝트의 개발을 시작하기 전에는 꼭 한번씩 읽는 책이다. 조금더 TDD를 잘 써보고 싶은 마음에서 매번 새로운 마음으로 읽어본다.
하지만, 매번 사용의 어려움을 느끼고, 그러면서 새로운 방법과 접근 방법을 배워갈수 있도론 Hint를 준다.

개인적으로는, 집에서 내가 코드를 작성할 때, TDD를 이용하여 Code Coverage를 측정하면, 평균적으로 90%~94%정도의 Coverage를 측정할 수 있다. 상당히 높은 수치이다. 코드의 질적인 면과 효율적인 면에서도, 아무생각 없이 junit을 이용한 코드를 짤 때보다는 높다. 물론, 경험상 TDD를 위한 코드를 작성하기 전에 생각해야 하는 시간을 상대적으로 늘어난다. 그러나 이역시도 클라스와 함수에 대한 명세서가 정확하고 명확하게 정의되어 있는 상태에서 시작한다면 아무런 문제가 되지 않는다. 테스트 코드를 위한 시간이 더 많이 필요로 하지만, Refactoring을 해야 하거나, 시스템 적으로 build와 testing을 해야 할 때 이 코드들은 큰 이익을 안겨준다.

내가 이전까지 사용하던 방식들은 Junit 3.8에서 제공하는 방식으로 이용해 왔다. 4.x 제공하는 기능들에 대한 간단한 사용법들은 알고 있었지만, 이 전에 작성했던 코드들와 게으름으로 다른 기능들에 대한 공부를 안하고 이제까지 버티어 왔다. 이 번에 Google App Engine Java버전을 분석하면서, 짜 넣을 코드들에 대한 테스트를 작성하면, Junit 4.x 버전을 공부하기로 마음 먹었다.

이를 위하여 몇가지 공부를 위한 사이트를 검색하면서, 링크들을 찾아 보았는데,
- IBM의 Developer Networks에 올라와 있는 글이 이해에 도움이 주었다.
- 그리고, www.junit.org 에서 소개하고 있는 글들이 유용하다.
           . New JUnit 4.x Howto + updated JUnit 3.x Howto 
           . JUnit 4.x Quick Tutorial
           . JUnit 4 in 60 Seconds
           . An early look at JUnit 4
Junit 4는 최근에 4.6 버전의 Release를 끝 마쳤다.

테스트를 작성하는 것은 개발자에게 많은 노력을 요한다. 아마도 개발한 코드보다 더 많은 코드들을 작성해야 하는 수고들이 뒤 따라야 할 것이다. 남에게 보기기 위한 다면 적당히 해도 좋다. 그러나 자신을 위하고 자신이 만든 코드를 위한다면, 요율적이고 효과적인 방법을 찾도록 노력해야 한다.

결국, SW 개발자는 자신의 코드로 나를 드러내야 하기 때문이다.
최선이라 함은 열심히 하는 것을 의미하진 않는다, 좋은 결과를 얻을 수 있는 과정을 최선이라고 생각한다.


 
 

'공부하는 것 > jUnit' 카테고리의 다른 글

Junit 4 공부를 시작하면서...  (0) 2009.05.23
Posted by 행복상자
Spring Source에서 새로운 툴을 하나 발표하려는 것 같다.
미국 시간으로 어제 "Roo Alpha 2 is now available for download" 라는 제목으로 글이 하나 올라왔는데, 생소한 이름의 툴이 하나 올라왔는데, 기존에 진행되었던 프로젝트와는 많이 생소한 내용이었다.

"Roo Alpha 2" 라는 이름으로 이미 Relesed 된 상태로, 이미 국내에서도 여러 개발자들이 관심을 갖고 살펴보고 있는 듯하다. 이는 SpringSource의 Tool Suite(STS)에 Roo Plugin으로 포함되어져 있고, 이들은 "introduction to Roo" 라는 블로그의 글을 통해서 "Roo"에 대해서 간략하게 소개하고 있다.
간단하게 Roo는  SpringSouce 오픈 소스 프로젝트이고, TDD를 위한 툴이고 이를 위해서 Shell을 개발자에게 제공한다. 그리고 Roo는 개발자가가 새로운 언어를 배우지 않고 쉽고 빠르게 그들의 Application을 개발 할 수 있도록 설계되었다고 한다.

Roo는 무료로 사용할 수 있는 툴인데, 이번주, 즉 5월 7일자(미국시간)로 무료로 다운받아 사용할 수 있다는 것이다. 이에 대해서 시간 제약과 같은 규제는 따로 없다.
우리 시간으로 5월 8일에 다운 받아 쓸수 있다는 말이다. (참조: http://www.springsource.com/products/sts)

Roo는 나에게는 아주 생소한 주제이다. 그래서 잠깐 구글링을 해보 았는데, 국내의 여러개발자들이 벌써 이를 테스트하고 분석하고 있는 중이었는데, 그중 특이한 것은 이 Roo가 갑자기 하늘에서 떨어진 것은 아니라는 것이다.
이미 일민(Toby)이가 이를 대한 소개를 한 글이 있었다. 2006년도에 TES2006에 참석해서 배운 내용을 정리했던 것인데 "TSE2006 넷째날 두번째 세션 - ROO"를 보면 이해에 도움이 될거라 생각된다.
그가 2006년에 Roo에 대해 알았다면, 이는 참 오래된 감춰진 프로젝트의 하나일 것이다.

그리고, "Introducing Spring ROO: Part 1" 의 글을 보면, 현재의 Roo에 대한 간략한 소개와 설치에 대한 설명들이 있다. 이름 참조하면 설치에 무리가 없을 거라 생각되고, 참고로 여기서는 A1 버전을 사용하였다.

그리고 지난주에 유럽에서 열렸던 SpringOne에서 발료되었던 세션중에 "Presentation: "Extreme Productivity in Application Development"을 보면 좀더 새로운 Roo에 대한 정보를 얻을 수 있을 것이다.

최근에 Roo에 대한 새로운 이름에 대해서 투표를 진행했는데, Roo도 괜찮은 이름인것 같다. 어떤 이름으로 다시 공개될지 모르지만 현재는 Roo이고, 이는 당분간은 유지 될거라 생각된다.
(투표에 관심있는 사람은 http://cloud.springsource.com/vote 를 한번 찾아가 보시길... )
Roo 1.0 Release는 6월 중순에 발표될거고, 1.0 GA버전은 올해말에 공개될 예정이다.

Roo를 사용하게 되면 어떤식으로 프로그램 방법이 바뀔지는 아직 감은 없지만, 많은 사람들이 관시을 가지고 있었던 프로젝트 였던만큼, 큰 반향을 일으킬 소지는 충분히 있다. 간단하게 작성된 소스들을 보더라도, AspectJ와 많은 Anotaion들이 사용이 된다. 중요한 것은 새로운 것을 익히고 쓰기 위해서는 기본에 충실해야 한다는 것이다. 이를 쓰기 위해서도 역시 기본적인 개념과 사용법에 대해서 익숙해질 필요가 있다.

아무리 좋은 도구라도 사용하는 사람이 익숙하지 않다면, 좋은 인상을 주기 어렵다. 새로운 것을 배우는데 익숙하거나 즐기는 사람이라면 다르겠지만, 자기가 하고 있는 분야만이 전부라고 생각하는 소아적인 개발자와 관리자를 깨우치기는 정말로 어렵기 때문이다. 그래서 "돼지목에 진주"라는 말이 있나 보다.

Posted by 행복상자

내가  개발자로서 좋아 하는 책이 여러권있다.
굳이 내가 개발자임을 강조하는 것은, 현재 까지는 나의 생업이고(앞으로도 그렇겠지만) 아직까자 내가 가장 좋아하는 일이다.

새로운 것을 알아가고, 나의 손으로 창조하는 것이 비단 Programer 뿐이겠는가?
사람들의 눈으로 보이는 잣대로의 창조적인 작업이 아니라, 내손을 통해서 뿜어져 나오는 Code로 인해서 무언가가 만들어진다는 작가적 또는 예술가적인 희열을 비슷하게 경험할 수 있다는 것이 항상 새롭다.

내가 좋아하는 책 중에는 kant Beck이 저술했고, 국내에서는 김창준씨아 강규영씨가 옮겨서 소개진 테스트 주도 개발 이라는 책이있다. 처음 이책은 접하게 된것은 2005년 초이다.
TDD(Test Driven Development)라는 것은 나와 같이 일했던 연승훈이라는 분을 통해서 처음 알게되었다. 그래서 관심을 두기는 했지만 프로젝트에 적용하기에는 참 쉬지 않았다. Junit와 xUnit에 대해서 한국에서도 많은 사람들에게 소개되었지만, 정말 제대로 사용하는 사람들은 찾아보기 어려웠으며(이는 지금도 마찮가지이다.), 이를 적용한다고 해도 버그는 사라지지 않았다. 그리고 xUnint과 같은 Unit 테스트 툴들을 사용할 때, 정말 좋은지에 대해서 긍정하는 사람들도 그래 많지 않았다. (아마도 테스트 코드를 작성하는데, 추가적인 공수가 들었기 때문이라고 생각된다.)

지금도 많은 기업(어느 정도가 규모가 되는 회사)들은 jUnit를 도입하고, 이를 범용적으로 이용할 수 있도록 개발 프로세스와 개발시에 중요한 업무(?)로 정의해서 이를 지키도록 강요아닌 강요를 하고 있다.
개발자가 필요하다고 생각되면, 이를 사용하지 말라고 해도 몰래 사용할 것이다. 필요성과 함께 정확한 사용에 대한 교육이 당연히 뒤 따라 다녀야 한다. 이는 전적으로 나의 개인적인 생각이다. 아직도 책 하나 던져주고 담 주까지 익히라고 하는 과거의 관행은 없어졌지만 , 프로그램의 코드를 생산하는 일이 창조적이라고 생각한다면 반드시 피해야 한다. 하지만 좋은 스승은 그때 당시에 찾기 무척 어려웠다. 잡지(마이크로 소프트웨어)에서 간간히 소개가 되고는 있었지만, TDD도 xUnit은 이거라고 정의내려주는 사람은 좀처럼 찾아보기 힘들었다.

개발자에 의한,개발자를 위한 여러가지 것들에 관심이 많았던 나는 2005년 우연히 서점에서 김창준씨와 강규영씨가 번영한 켄트 백의 TDD책을 발견하고 바로 구매해서 보게되었다.
내가 좋안 하는 책들은 당연하게도, 여러번 반복해서 읽게 되는 책들인데, 이는 나의 필요에 의해서이다. 아니 내가 그들 만큼 똑똑하지 못하기 때문이다. 나는 지극히 평범하기 때문에, 나보다 앞선 선배들과 똑똑한 그들의 조언이 항상 필요하기 때문이다.

                                                    (바로 이책이다.)

내가 정확하게 2005년 3월에 그 책을 구입한 이후로 1년에 거의 2~3차례 이책을 탐독을 한다.  올해도 벌써 2번째 이책을 들여다 보고 있다. 아마 올해까지 거의 9~10회 정도를 본것 같다. 하지만 정확하게 그분(캔트 백)의 의도를 모르기 때문에 매년 이책을 반복해서 보는 것이다. 역시 나는 덜 똑똑한 사람이다. 남들은 쉽게 잘하는데...(백형 부러워요.)

하지만, 내가 이해하는 것은 TDD는 개발자 자신을 위한 것이기도 하지만, 프로젝트에 참여하는 모든 개발자와 테스트를 담담한 사람들과 결과물을 받을 사람들에게 반드시 필요하다.
이의 결과로 산출된 코드는 내가 담당한 코드의 결과를 예측케 하는데, 이는 코드의 명세서와 같은 역할을 한다. 일반적으로 잘 설계된 시스템과 Architect는 계약 관계를 어떤계 표시하는 가에 달려있다. 이는 설계자와 코드를 작성하는 개발자와 그리고 이를 테스트할 테스터와 최종 산출물을 사용할 이름 모를 사용자와의 약속이기 때문이다.

내가 작성할 코드의 결과를 바라보는 것은, 농부가 씨를 뿌릴때 가을에 거두어야 하는 작물이 무었인지 정확하기 아는 것과 같다. 이에 맞추어서 작물에 필요한 양분과 환경을 만들어주고 추수하는 것처럼 결과에 대해 명확히 알고 씨를 뿌리는 것은 정말 중요하다. (코드 명세서는 이래서 중요하다.) TDD를 통해 작성된 코드는 정확이 이래야 한다. 무엇을 정의하고 결과로 나오야 하는 것이 무엇이지 아는 것과 모르는 것의 차이는 분명하다.
따라서 똑같은 클래스에 대해서 테스트 할때 어떤 사람은 20개를 작성하는데 어떤 사람은 200개 가까운 테스트 코드를 작성하기도 하다. (아마도 한국에는 없을 것이다.)

이렇게 작성된 TDD의 테스트 코드는 리펙토링에도 유용하다. 리펙토링은 코드의 외적인 모습을 유지하면서 내부 구조를 변경하는 것이다. 이는 리펙토링은 결코 Architecture를 흔들어서는 안된고, 현재의 상태를 가장 최적의 상태를 만드는데 초점을 두어야 한다는 의미이다.

내가 켄트 백의 책을 프로젝트의 시작 초기에 항상 읽는 이유중에 하나는 내가 부족한 면이 가장 크지만, 그의 의도와 경험을 내것으로 만들고 싶은 이유 또한 크다.  테스트 코드를 작성하지 않고는 결코 불안해서 일이 안된다는 그의 말처럼, 중요한 것을 중요하게 여기면서 프로젝트에 임하고 싶기 때문이다.
사실 켄트백과 나는 다른 점이 나는 먼저 파란 불이 들어오면, 여기서 코딩을 시작한다. 그는 붉은 불에서 시작하지만, 나는 정말 붉은 불이 두럽다.

자신에게 맞는 코딩 스타일과 방법이 있다. 이를 무시하면 안된다. 나에게는 TDD와 Unit Test는 분명이 많는 방법이지만 아직 나만의 스타일은 없다. 매년 내가 그의 책은 읽는 것은 결국은 나의 스타일이 아직 없기 때문이기도 하다. (글을 쓰다가 느낀점이다. 글은 나를 바라보네 만드는 군.)
아마도, 내가 나만의 스타일을 통해서 이전보다 많은 부분이 채워지고 다듬어 진다면, 그의 책을 좀도 쉽게 볼수도 있을 것이다. (매년 볼때마다 꼭 이렇게 해야하는가에 대해 그에게 의문을 갖지만, 결국은 그도 매번 최선을 찾아서 일할거라 생각이 든다.)

Posted by 행복상자