달력

4

« 2021/4 »

  •  
  •  
  •  
  •  
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  •  
기다렸던 사람들이 많았을 것 같다. 이제야, 오늘에야 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 행복상자

댓글을 달아 주세요

2009. 5. 23. 08:35

Junit 4 공부를 시작하면서... 공부하는 것/jUnit2009. 5. 23. 08:35

내가 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 행복상자

댓글을 달아 주세요

어제는 근로자의 날이라서 출근하지는 않았었다. 그리고 전날은 부부동반 모임이 있어서, 늦에 들어온 것을 핑계삼아 간만에 게으름도 피우고 그랬다. 아니 사실은 게으름을 피운 것운 것이 아니라, 감기인지 못살인지 몸이 좋지 않아서 누워서 오전을 보냈다. 선천적으로 늦잠을 좋아하지 않는 관계로 시간이 무척 아까웠다.

무엇을 할까 고민하다가, Google App Engine에 스프링으로 간단한 페이지를 한번 올려봐야지라는 생각이 들었다.
최근에 Google의 Eclipse 플러그인과 SDK는 이미 설치해서 간단한 것들은 적용해 본 상태여서, Google의 App Engine의 인증만 남은 상태이므로 남은 작업은 정말 간단하다.

만약 Eclipse에 Google App Engine Plugin과 SDK를 설치 하지 않았으며,
이전에 블로그에 올렸던 다음의  글을 "Google App Engine SDK 설치 및 실행" 를 참조 하기 바란다.

위와 같이 Google App Engine을 위한 기본 환경을 만들었으면, Spring Framework를 다운 받아야 한다.
이미 Spring Framework를 이용하여 개발한 경험이 있는 개발자라면, 기존에 가지고 있던 Library들을 그대로 사용하면 되지만, 그렇지 않은 개발자라면 www.springframework.org 에서 다운 받아야 한다.
                      - Spring Framework 2.5 Dependency Version Download

지금은 SpringFramework 3.0M3가 공개되고 있지만, 정식 Release된 2.5.5버전을 예제 작성에 사용할 것이다.
(물론 다른 버전을 사용해도 큰 영향은 없을거라 생각된다. 환경만 잘 맞추어 주면 말이다.)

자 이제 본론으로 들어가서, Google App Engine의 Eclipse Plugin을 정상적으로 설치하게 되면, Eclipse의 상단 메뉴텝에 다음과 같이 3개의 아이콘들이 생겨난 것을 볼수 있을 것이다.

   



위에 첨부한 메뉴 이미지 중에서 왼쪽에 있는 메뉴 아이템을 클릭하여 "New Web Application Project"창을 아래와 같이 띄운다.

위의 창에 생성할 프로젝트 이름을 입력하고, 기본적으로 생성할 패키지명도 입력한다. 만약 Google Web Toolket를 사용하기 원하지 않으면 체크박스에서 체크 표시를 지워주고 하단에 있는 "Finish"버튼을 클릭하면 된다.

프로젝트를 생성하면 기본적인 Servlet을 예제로 제공한다. 자 일단 테스트를 위해서 이를 실행해 보자.
아래와 같이 "Debug As" 메뉴의 서브 메뉴인 "Web Application" 를 실행시키면 웹서버가 실행된다.



이를 확인하기 위해서는 웹브라우져의 주소창에 "http://localhost:8080" 입력하여 실행하면 된다.

정상적으로 동작하는 것을 확인하면, 이제 스프링을 실행할 수 있는 환경을 만들어 보겠다.
예제는 아는 사람들에게는 잘 알려져 있는 "step-by-step" 를 예제로 작업할 것이다. 환경을 만들어 주기 위해서는 이전에 다운 받은 Springframework에서 Spring.jar, Spring-mvc.jar 그리고 common-log.jar 파일을 WEB-INF/lib 디렉토리 아래로 복사한다. (아래  그림 참조)

common-log.jar 파일은 Google에서 제공하는 logging 패키지를 이용해도 되지만, Spring의 "DispatcherServlet"을 로딩할때 에러가 나기 때문에 넣어준 것이다. 위의 "step-by-step" 예제를 따라하면, 기본적인 웹페이지를 작성할 수 있을 것이다. 다만, "Ant Build"에 관한 내용과 "Unit Test"에 관한 부분은 크게 신경 쓰지 않아도 된다.

Spring의 "DispatcherServlet"을 이용한 기본적인 예제는 큰 에러 없이 작성될거라 믿는다. 만약 에러가 난다면, Google의 SDK없이 만들어서 돌려보기 바란다. 기본적인 개념을 익히는데 큰 도움이 될거라 믿는다.

일단 http://localhost:8080 을 이용해서 무리가 없으면,



위 이미지의 메뉴중(붉은 박스로 안에 있는)에 세번째 아이템(비행기 모양의 버튼)을 클릭을 하여 "Deploy Project to Google App Engine" 윈도우를 띄운다. 



위와 같은 창이 뜨면, 입력할 값들을 입력박스에 채워 넣고 Deploy를 실행하면 되는데, 이를 위해서는 Google App Engine의 인증이 필요하다. 인증을 위해서는 이미 구글의 Account가 있어야 하고, 이를 이용하여 Deplore를 진행할 수 있다.

아래의 이미지는 서버에서 서비스할 application을 위한 기본적인 정보인데, 간단하게 필요한 내용을 입력하면 된다.


위 화면의 "Applicatiion Identifier"는 자신이 원하는 App Engine상의 sub 도메인 역할을 하는 것이고, "Appication Title" 은 적절한 이름을 넣어주면 된다. 인증 관련된 부분은 특별한 설정 없이 그래도 놓은면, 누구다 다 접속이 가능하고, 별도의 추가 설정이 필요하면 "Edit" 링크를 눌러서 추가 설정을 해주면 된다. (자세한 내용은 구글에서 제공하는 가이드를 참고하기 바란다.)
 
설정을 마쳤으면 "Save" 버튼을 클릭하면 서버상의 설정을 마쳐지게 된다.

내가 작성한 셈플 프로그램은 여기에 있다.
    Sample Progrom 링크 : http://happyzoo2009.appspot.com/hello.htm

추가적인 사항으로는 Google App Engine에서 제공하는 DB는 공식적으로는 없다. 다만 Google App Engine의 Datastory를 이용이 가능하다. 하지만 이 역시도 Google에서 제공하는 Library를 통해서 JPA와 JDO틀 통한 이용이 가능하다. 이를 이용해서 Persistance 데이터들을 관리해서 사용해야 한다. 이의 사용은 기존의 관계형 DB와는 차이가 있다. 때문에 제대로 이용하기 위해서는 역시 공부하고, 분석하는 시간들이 필요하다.

하지만, 관계형 DB의 사용도 가능하나 역시 제약이 뒤 따른다. HSQLDB를 이용하여 in-memory상에서 동작을 시키는 경우이다. (이런 경우는 Hibernate의 이용이 가능하다. ) 
 
이제는 데이터를 어떤식으로 다룰지에 대한 고민들이 남아있다.
한가지 한가지씩 배워나가는 즐거움이 있는 장남감이다. SprignSource에선 Groovy와 Grails을 이용한 예제를 벌써 내 놓았다. 아직은 이들을 적용하고 싶은 생각은 없지만, 조만간 한번을 이들에 대해서도 공부하고 알아야 겠다는 생각은 늘상 가지고 있다. 일단은 Jruby를 먼저 적용해 보고 싶은 생각이 크다.





Posted by 행복상자

댓글을 달아 주세요