첫째세션 실시간 포스팅. 

Spring은 testing-tool? ;-)

Dependency Injection enables Unit Tests. 한 unit을 테스트하는 것. i.e. class in isolation.  So no dependent classes => Use mocks/stubs instead of the real classes. Spring을 쓰면 이런 테스트를 위해서 factories나 Singleonts를 바꾸는 짓을 안해도 된다.

Integration Test: 여러개의 classes를 결합해서 테스트. Spring의 Integraton test기능은 빠방하다. :) 사실 나는 이런 테스트 기능이 있다는 것을 AppFuse소스를 분석하면서 알게되었다. Matt은 Spring의 테스트와 관련해서 한동안 포럼에서 활발한 활동을 했었다. AppFuse는 초기부터 이런 Spring기반의 테스트를 일반적인 애플리케이션 구조에 적용해왔다.

Spring은 Explicit dependency를 통해서 unit test를 가능하게 하고. Environment Idenpendence와 Integration test package를 통해서 Integration Testㄹ Test reusable을 통해서 System-test를 가능하게 한다. 마지막 얘기는 뭐지 -_-? Automation Test/CI얘기구나.

여기까지는 기본이고.

There are more testings!

Acceptance Tests

Business requirements/use cases에 대한 구현상의 에러를 찾는 것. 정형화된 유구사항이고 system complete test시에 자주 일어난다. 수동테스트를 하는 경우가 많다. 그래서 반복하기가 힘들다.

Fit/FitNesses

궁국적인 목적인 고객이 test를 작성하게 하는 것이다. XP! 근데 어떻게 해야 하나?

Fit/FitNesse는 HTML tables을 interpret한다. Table은 java class에 의해서 evaluate된다.(Fixture) ?? 데모를 봐야 이해가 되겠다.

HTML파일 안에 있는 Table안에 테스팅 데이터와 룰을 정의한다. (fit.xml)

FitNesse는 사이트를 통해서 테스트를 관리한다. 일종의 테스트를 위한 위키이다. non-tech people을 위해서 더 유용하다.

(Mac에서 데모를 하는데 화면 일부분을 쉽게 zoom해서 보여준다. 오옷. 이런 기능이 있었나)

구현방법

간단한 클래스를 만들고 테스트를 위한 method를 추가한다. 이것이 fit정보의 테이블에 있는 것과 연동을 해서 동작하게 된다.

만드는 클래스는 …Fixture를 상속한 것으로 errors()메소드 안에 검증을 위한 코드를 넣는다. @Configurable을 이용하면 Spring에 정의된 bean을 불러와 사용할 수 있다. 당연히 AspectJ설정이 되어있어야 한다.

일종의 비즈니스 로직구현의 테스트를 위한 툴이라고 볼 수 있다. (G)UI테스트는 아니다. 코도로 작성하는 테스트보다 훨씬 간편하고 커스토머에 의해서 주도된 테스트가 가능하다는 장점이 있다. Rollback기능등을 지원한다.

아주 쉽게 로직 테스트를 만들 수 있다는 게 장점, RMI, HttpInvoker, JMX등을 위한 테스트도 가능하다.

Spring-FitNesse

Generic Fit exporter를 만들기. Spring bean과 손쉬운 연동. i.e. generic SpringColumnFixture.

BeanWrapperImpl: property를 이름으로 액세스 할 수 있다. 이름으로 set할 수도 있다. Spring의 가장 핵심기능 중의 하나이다.

Service layer의 method를 위한 parameter에 사용할 수 있다. 기본타입이 아닌 경우는 PropertyEditor를 적용할 수 있다. PropertyEditorRegisar로 자동 연동이 된다. Test데이터를 어떤 형태의 external format으로도 작성할 수 있게 해준다.

왠지 RoR의 Fixture나 그것을 이용한 테스트를 보는 것 같다. 그보다는 훨씬 복잡한 것이 가능하겠지만.

두가지 Fixtures

SpringColumnFixture: 하나의 서비스에 여러개의 테스트 데이터를 적용하게 만들어준다.

SpringActionFixture: 테스트 시나리오를 가지고 테스트 할 수 있게 만들어준다. Enter와 Press로 구성. Enter는 데이터를 삽입하거나 environment를 구성하는 것이고 press는 method call이다.  Check는 검증.

Complex results에 대한 테스트는? 역시 PropertyEditor와 BeanWrapperImpl을 이용해서 만들면 된다.

GUI Interaction의 개념을 적용한 테스트가 가능하다.

Fit

Spring은 Fit을 사용하기 좋은 환경을 제공한다. Generic adapter를 쉽게 만들 수 있고 테스트를 만들기 쉽다. Spring덕분이다.

spring-fitnesse.dev.java.net: 하지만 아직 alpha라는 거. (Fit/FitNesse는 아니고)

 

상당히 흥미로운 기술이다. Business Logic의 functional/integration test는 지금까지 JUnit Test를 직접만들어서 했는데. 아무래도 코드의 양이 상당하기 때문에 개발자들이 충분한 테스트를 만들기 힘들고 고객이 하기는 더욱 어려움이 있다. 그런 면에서는 많은 장점이 있을 것 같다. 하지만 복잡한 테스트케이스를 다 카바할 수 있을지는 검토해 볼 필요가 있다.

WebTool같은 Web functional testing tool과 결합해서 acceptance/customer test용으로 사용해 보는 것을 고려해봐야겠다. Testing분야는 아직도 개척할 영역이 만다. Testing이외에도 Spring과 AOP가 가진 여러 구조적인 장점을 잘 활용할 아이디어를 찾아보자.

Stress Test

JMeter: 유명하지만 생각보다 많이 안쓰는 것. I21은 유럽에 기반을 둔 조직이라 영어를 모국어로 쓰지 않는 국가의 사람들도 많다. 지금 강사도 그런듯. JMeter의 메뉴명이 Datei, Bearbeiten, Optionen등등이다. 독일어인가? 암튼 그래도 영어로 강의는 잘한다.

JMeter의 장점은 쉽고. HTTP requets를 레코드해서 후에 수정할 수도 있다는 것.

Profiler는 너무 detailed할 수 있다. 오버헤드가 매우 클 수 있다. Java자체에만 포커스를 두는 것으로 충분하지 않을 경우가 많다. DB등등에 대한 관심도 필요하다.

그럼 각 Layer별로 성능을 테스트하려면? JAMon(자몽?)이 있다. Monitoring Framework이다. Spring은 JAMon interceptor를 지원한다. 결과는 web으로 publish할 수 있다.

JAMonFilter: serlvet filter로 등록해서 사용.

Controller의 profiling:

전체 HTTP request에서 controller부분을 빼면? View rendering시간이다. 오호. DAO나 service layer의 profiling을 하고 싶을 때도 사용하긍. AOP니까.

Profiling SQL: 각각의 query시간을 측정하는게 가능하다.

JAMonDataSource를 만들어서 사용한다. 일종의 proxy data source이다.

결과를 보여주는 중. 오옷. 전체 HTTP request뿐만아니라 각 레이어의 결과를 효과적으로 보여준다. 고급 APM툴에서나 볼 수 있는 기능을 아주 간단히 구현해 준다. JAMonDataSource를 쓰면 실행 된 SQL도 볼 수 있다.

 Why JAMon?

SpringAOP를 이용해서 손쉽게 적용이 가능.

오버헤드가 매우 적다. Production시스템에도 적용가능. SQL/View rendering을 포함한 모든 layer를 구분해서 볼 수 있다.

Spring의 IoC덕에 DataSource wrapper를 쉽게 삽입할 수 있다는 것.

결론

DI를 이용한 UnitTest/IntegrationTest 뿐만 아니라 DO테스트와 service테스트를 자동화할 수 있다. (DDD에는 어떨까 한번 생각해보자) JMeter, JAMon을 이용하면 레이어별로 더 정밀한 테스트를 적은 overhead를 가지고 테스트할 수 있다.

 

 

Related posts:

  1. Rod Johnson의 Testing with Spring
  2. TSE2006 넷째날 두번째 세션 – ROO
  3. TSE2006 셋째날 세션1 – Applying DDD int the Enterprise with AspectJ
  4. Spring 공부 다시 시작
  5. Spring에 관한 흥미로운 글 몇가지
  6. 공부할 시간이 없다고?
  7. SpringFramework의 바이블 – Pro Spring
  8. Generic DAO Pattern with JDK5.0
  9. 7월 7일 Spring활용적략 세미나
  10. Mock Object의 위험성?
  11. Spring vs. EJB3
  12. Spring활용전략 세미나를 마치고
  13. 망해가는 EJB 최후의 발악인가? Mastering EJB3 (4th Ed)
  14. SpringFramework vs. J2EE?
  15. 스프링프레임워크 관련 글/스크린캐스트 주제 선정

Facebook comments:

to “TSE2006 넷째날 세션1 – Meeting Requirements through Acceptance and Stress Testing”

Leave a Reply

(required)

(required)

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

© 2017 Toby's Epril Suffusion theme by Sayontan Sinha