달력

4

« 2024/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
.. .. ..

 

 

강력하고 새로운 웹 부하테스트 도구 Gatling으로 JBoss 부하테스트 하기

 

.
:
Posted by .07274.
2013. 12. 6. 10:34

Nexus 설치후 초기 설정 I.lib()/I.lib(etc)2013. 12. 6. 10:34

.. .. ..

 

 

[펌] : http://stove99.tistory.com/75

 

관리자로 로그인 한 다음 왼쪽 메뉴중에 Repositories 를 클릭하면 디폴트로 등록된 리파지토리들 목록이 나온다.




먼저 목록중에 Public Repositoires 를 클릭하면 아래쪽에 상세내용이 나오는데 Configuration 탭으로 이동한다.

 


Ordered Group Repositories 에 디폴트로 여러개가 등록도 있을껀데 일단 Maven Central 만 남기고 다 빼버리자, 나중에 원하는걸 필요할때마다 맨들어서 추가해 주면 된다.

요부분에서도 그동안의 고정관념 때문에 살짝 삽질을 했는데, 나의 고정관념 상으로는 죠렇게 박스 두개가 있으면 오른쪽 박스가 당연히 선택할 대상들이 들어가는 박스라고 생각해서 아무리 설정을 해도 안되는 것이였다 -_-;

외국 사람들은 반대로 생각하나 보다 -_-;  아무튼 결론적으로 하나로 묶어줄 애들은 왼쪽 Ordered Group Repositories 에다 추가시켜주면 된다 -_-

죠렇게 해 준다음에 아래쪽에 Save 버튼을 눌러 저장을 해준다.





고 다음으로 설정할 것은 리파지토리 목록중에 Maven Central 을 설정하는 것이다. 역시 클릭하면 아래쪽에 상세화면이 나오는데 Configuration 탭으로 이동하자.

 


여기서 할일은 Download Remote Indexes 가 디폴트로 False 로 되 있을건데 고걸 True 로 바꿔준다음 Save!

Download Remote Indexes 가 True 로 되있으면, Remote Storage Location 으로 설정된 http://repo1.maven.org/maven2 에 접속해서 인덱스 파일을 받아와서 고 인덱스 파일이랑 똑같이 나의 서버에 인덱스를 맨들어 준다.

Save 를 하면 인덱스파일을 다운로드 받아 인덱스를 업데이트 하는 작업이 시작된다. 이 작업이 완료되면 리프레쉬를 한다음에, 상단의 탭중Browse Index 탭을 클릭해보면 전에 하나도 안보이던 목록들이 쪽 생성이 되 있을 것이다.



인덱싱하는 작업이 쪼매 오래 걸리는데 작업이 완료 됬는지 계속 작업중인지 볼려면 왼쪽 메뉴중 Administration > Scheduled Tasks 를 클릭해 보면 알수 있다.

 


이 메뉴는 현재 Nexus 에서 돌아가고 있는 Task 를 보거나 아니면 원하는 Task를 스캐쥴링 하도록 등록하는 메뉴인것 같다.

아무튼 Task 목록을 보면 Maven Central 리파지토리의 인덱스를 다운로드 받아서 인덱싱을 하는 작업이 진행중인것을 볼수 있다.

작업이 완료되면 목록에서 사라지는데, 상단의 리프레쉬 버튼을 클릭하다 보면 언젠가는 사라질 것이다. -_-;



인덱싱 작업이 완료되면 이제부터 정상적인 사설 리파지토리 기능을 수행할 수 있다.!!




인덱싱된 결과를 볼려면 Pubic Repositories 를 클릭한다음 Browse Index 탭을 클릭해 보자.

 


인덱싱을 하기전에는 안보이던 여러가지 목록들이 간지나게 쫙 펼쳐져 있다.

※ Browse Index 탭에 보여지는 것들은 내가 맨든 사설리파지토리로 제공가능한 디펜던시들이지 아직 나의 서버로 다운로드가 된 상태는 아니다.
※ 나의 서버로 누군가가 디펜던시를 요청하면 일단 최초로 proxy 대상 리파지토리에서 해당 디펜던시를 다운로드 받아 이후 요청부터 캐싱을 하게 된다
※  현재 다운로드 받아 캐싱하고 있는 디펜던시들을 볼려면 Browse Storage 탭을 클릭해 보면 된다.





여기까지만 하면 일단 설정을 대충 다 끝났고 maven 에서 나의 서버를 바라보게 설정만 해주면 된다.

위 스크린샷에서 보면 리파지토리 목록 왼 오른쪽에 있는 Repository Path를 요렇게 pom.xml 파일의 repository 로 설정해 주거나 바꿔주면 된다.

많은 현재 디폴트로 등록된 리파지토리들이 많이 있지만 이중에서 다른 리파지토리들을 하나로 묶어주는 group 타입의 public 리파지토리를 메이븐에서 바라보도록 설정하자~

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
<repositories>
    <repository>
        <id>central</id>
        <releases><enabled>true</enabled></releases>
        <snapshots><enabled>true</enabled></snapshots>
    </repository>
</repositories>
 
<pluginRepositories>
    <pluginRepository>
        <id>central</id>
        <releases><enabled>true</enabled></releases>
        <snapshots><enabled>true</enabled></snapshots>
    </pluginRepository>
</pluginRepositories>



Nexus 설명서를 보면 maven 의 settings.xml 파일인가 고걸 수정하게 하던데 그러면 다른 개발자들도 settings.xml 을 귀찮게 수정해야 하기 때문에 나는 svn으로 공유되는 pom.xml 파일을 수정했다.

 

pom.xml 파일을 수정하지 않고 MAVEN_HOME/conf/settings.xml의 파일에 add 하는 방법은 아래와 같다.

 

 <mirror>
      <id>nexus-central</id>
      <mirrorOf>*</mirrorOf>
      <name>Mirror.</name>
      <url>http://127.0.0.1:8080/content/groups/public</url>
    </mirror>


아무튼 요렇게 한 후 나의 서버가 잘 돌아가나 테스트를 해보기 위해 pom.xml 파일에 디펜던시를 아무거나 하나 추가해 보자.

1
2
3
4
5
<dependency>
    <groupId>abbot</groupId>
    <artifactId>abbot</artifactId>
    <version>0.12.3</version>
</dependency>



음~ 잘되는 것 같다. 확실히 확인하기 위해서 위에서 설명했던 현재 캐싱된 디펜던시들을 보여주는 Browse Storage 탭을 클릭해 보면 pom.xml 파일에 추가했던 abbot 뭐시기가 캐싱된 것을 확인할 수 있다.

 



지금까지 한 설정은 딸랑 maven central 리파지토리만 바라보도록 설정했는데, 필요에 따라 다른 외부 리파지토리를 proxy 타입으로 추가 시킨다음

하나로 묶어주는 기능을 하는 group 타입의 Public Repositories 에다 포함 시켜주고 maven 에서는 이 public 리파지토리만 바라보도록 하면

pom.xml 파일에 추가적으로 <repository/> 를 추가할 필요도 없고 한번 캐싱된건 나의 서버에서 빠르게 다운로드 받을 수 있을 것이다.




이건 기본적인 사설 리파지토리 기능이고, 다음 포스트에서는 이렇게 맨들걸 쪼매 더 활용할 수 있도록 이것저것 다른 설정들을 쪼물거려 보겠다.

 

.
:
Posted by .07274.
.. .. ..


[펌] : http://jmnote.com/wiki/Httpd

.
:
Posted by .07274.
.. .. ..

 

 

[펌] : http://www.jami.name/67

 

 

프로그래밍할 때 EditPlus http://www.editplus.com/ 를 사용하고 있었는데..
사용한지는 꽤 오래된 듯 싶다. 아직까지 칸단위 편집을 거의 사용하지 않고 있었다.
(사실 그런게 있는지 몰랐었다. -0-)

alt + c 후 선택

1. alt + c (편집 > 선택 > 칸단위선택) 하면 칸단위 선택이 된다. (이건 종종 사용했었는데..) 편집할 곳을 적당히 선택


채워질 문자

2. alt + e f f (편집 > 모양 > 선택부분채우기) 하면 선택한 부분에 삽입/대체 등을 할 수 있다. 물론 UltraEdit http://www.ultraedit.com/ , AcroEdit http://www.acrosoft.pe.kr/ 처럼 보면서 바로 칸단위 편집이 되지는 않지만 유용하게 사욯할 듯 싶다.


결과

3. 위와 같은 결과를 얻는다. :)
종종 사용하게 될 듯 싶다.

'I.lib() > I.lib(etc)' 카테고리의 다른 글

Nexus 설치후 초기 설정  (1) 2013.12.06
리눅스에서 아파치 설치 및 설정  (0) 2013.11.08
부산 여행 Tip  (0) 2013.08.09
PMD Rule Set 정리 [펌]  (0) 2013.07.30
겔럭시 s 부두 패치 경로  (0) 2013.04.19
.
:
Posted by .07274.
2013. 8. 9. 11:29

부산 여행 Tip I.lib()/I.lib(etc)2013. 8. 9. 11:29

.. .. ..

[펌] : URL이 날아갔다 죄송 ㅜㅠ

 

여행 팁

부산 여행 꼼꼼 관광 정보

 

 

 

 

부산 여행, 이것도 모르고 가면 되나, 안 되나? 마!

여행에선 아는 것이 힘! 부산 여행에 유용한 알짜 정보를 모았다.

글 송보배 기자

교통정보

1일권

지하철을 4회 이상 이용할 경우 1일권이 더 유리하다. 1일권을 구입하면 발매 당일에 한해 횟수 제한 없이 지하철을 이용할 수 있다. 각 역 승차권 자동발매기에서 구입할 수 있으며 요금은 4000원이다.

교통카드

티머니 교통카드는 타 지역에서 사용하던 것이라도 그대로 이용할 수 있다. 후불 신용카드 역시 지역에 관계없이 사용 가능하다.

환승

교통카드 이용 시 버스나 지하철에서 내린 후 30분 이내에 다른 대중교통으로 갈아타면 2회까지 환승 할인을 받을 수 있다.

짐 보관

당장 필요 없는 짐이라면 지하철 물품보관함을 찾아보자. 1200~1500원의 비용으로 이용할 수 있다. 대부분의 지하철역에 물품보관함이 갖추어져 있는데 특히 자갈치역, 해운대역, 광안리역 등에는 사이즈별로 마련되어 여행자의 편의를 돕고 있다.

문의 1544-5005 www.humetro.busan.kr

숙박

찜질방

광안리 아쿠아펠리스호텔 찜질방(051-790-2345)과 해운대구의 로데오찜질타운(051-741-3753)은 널찍한 규모에 비해 덜 알려져 있어 도심보다 덜 붐비는 곳이다. 광안리의 호메르스호텔 찜질방(051-750-8056), 부산역 인근의 발리아쿠아랜드(051-442-1551)도 숙박이 가능한 찜질방이다.

게스트하우스

나 홀로 여행자나 여성 여행자라면 게스트하우스를 권할 만하다. 해운대 하이코리아호스텔(070-4409-3132), 해운대구 중동의 포비게스트하우스(051-746-7990)는 깔끔한 인테리어와 2만~3만원의 저렴한 비용으로 많은 여행객들이 찾는 곳.

호텔

가족 단위로 방문했다면 호텔이 편리하다. 해운대 파라다이스호텔(051-742-2121)은 해운대해수욕장의 특급 호텔 중에서도 단연 최고의 명성을 자랑한다. 달맞이고개 입구의 호텔일루아(051-744-1331)는 인근 호텔에 비해 비교적 저렴한 가격이 장점. 씨클라우드호텔(051-933-1000)은 피트니스센터, 수영장을 함께 이용할 수 있다. 동래에는 50년 전통의 농심호텔(051-550-2100)이 유명한데 온천욕 시설 허심청이 갖춰져 있다. 부산역이나 중앙동에서는 코모도호텔(051-466-9101)에 머물 만하다. 이순신 장군을 형상화한 독특한 외관이 특징. 광안리해수욕장 인근에는 호메르스호텔(051-750-8000)이 있다. 저렴한 비용의 호텔로는 토요코인이 제격. 현재 해운대지점(051-256-1045), 서면지점(051-638-1045), 부산역1지점(051-466-1045), 부산역2지점(051-442-1045)이 운영되고 있다.

부산 버스투어.jpg

부산 시티투어버스

시티투어 버스

순환형 버스로는 해운대와 태종대 코스가 매일 30분 간격으로 운영된다. 이층 버스가 특색 있고 관광지도 쉽게 둘러볼 수 있어서 인기 만점.

순환형 버스는 티켓 1장으로 해운대와 태종대 두 코스를 모두 이용할 수 있고 이 밖에 역사 문화 탐방 코스, 해동용궁사 코스, 을숙도 자연 생태 코스, 야경 코스도 하루 1~2회 운영된다.

출발 장소 부산역 광장

해운대 코스 부산역 - 부산박물관 - 광안리해수욕장 - 누리마루- 해운대해수욕장 - 해운대역 - 신세계백화점 - 시립미술관(벡스코) - 광안대교 - UN기념공원 - 부산역

태종대 코스 부산역 - 연안여객터미널 - 75광장 - 태종대 - 국립해양박물관 - 남항대교 - 송도해수욕장 - BIFF광장·자갈치 - 부산역

요금 어른 1만원, 어린이 5000원 문의 1688-0098, 051-464-9898

관광 문의처 안내

축제

부산국제영화제(10월 4~13일) 1688-3010

부산세계불꽃축제(10월 26~27일) 051-501-6051

관광안내소

부산역관광안내소 051-441-6565

남포동관광안내소 051-253-8253

송정관광안내소 051-749-5800

해운대종합관광안내소 051-749-5700

교통

철도 1544-7788

부산종합버스터미널 1577-9956

동부시외버스터미널 1688-9969

서부시외버스터미널 1577-8301

부산-유람선.jpg

바다를 가르는 태종대 유람선

유람선

팬스타크루즈 1577-9996

테즈락크루즈 051-463-7680

티파니21 051-743-2500

해운대관광유람선 051-742-2525

해운대·자갈치관광유람선 051-441-2525

태종대관광유람선 051-405-2900

 

'I.lib() > I.lib(etc)' 카테고리의 다른 글

리눅스에서 아파치 설치 및 설정  (0) 2013.11.08
에디트 플러스 (Edit Plus) 칸단위 선택  (1) 2013.08.14
PMD Rule Set 정리 [펌]  (0) 2013.07.30
겔럭시 s 부두 패치 경로  (0) 2013.04.19
[펌] TDD  (0) 2013.03.28
.
:
Posted by .07274.
2013. 7. 30. 14:36

PMD Rule Set 정리 [펌] I.lib()/I.lib(etc)2013. 7. 30. 14:36

.. .. ..
[펌] : http://blog.benelog.net/2702876

Rule Set Rule name Message 분류 의견 설명, 의견 사유 참고자료
Basic Rules EmptryInitializer
Warning 제외요망 PMD 5.0에서 추가될 룰로 Maven plugin에서는 지원되지 않음
Braces Rules IfStmtsMustUseBraces Avoid using if statements without curly braces Warning 논의필요 if문뒤의 한줄짜리 처리문도 {}가 없으면 경고를 줌. 가독성을 높여주므로 포함시키는 것이 바람직.
Code Size Rules TooManyMethods This class has too many methods, consider refactoring it. Warning 논의필요 한 클래스에 지나치게 많은 메소드가 포함되면 나는 경고. 적당한 클래스 크기를 정하는데 도움을 주나, 정말 논리적 연관성이 있는 작업을 많이 담고 있는 클래스도 존재할 수 있으므로 적정 숫자에 대해서는 논의 필요함
Controversial Rules OnlyOneReturnRule A method should have only one exit point, and that should be the last statement in the method Warning 제외요망 메서드 중간의 return문은 복잡한 조건문의 구조를 단순하게 하는데 도움이 경우가 많고, 권장하는 사례도 있음. 켄트백의 구현패턴 - 7장 중 '보호절'
Controversial Rules DataflowAnomalyAnalysis Found 'DD'-anomaly for variable ... Info 제외요망 전체 데이터의 흐름을 분석해서 return값과 상관없는 변수에 값을 쓴다든지 하는 상식적이지 않은 경우를 잡아내줌. 캐쉬나 interceptor등 그런 흐름이 꼭 필요한 코드도 경고해줘서 지나치게 많은 경고를 생성함
Controversial Rules Unused Modifer Avoid modifiers which are implied by the context Warning 논의필요 interface는 당연히 모든 method가 public이니 따로 선언해줄 필요가 없는 현상등을 주의를 줌. 개발자에 따라서는 public이 있는 것이 더 명시적이라고 생각할 수도 있고, 이미 모든 인터페이스가 public으로 다 선언되어 있는 상황에서는 개발자들에게는 무의미한 수정으로 인식될 위험도 있음.
Design Rules UnnecessaryLocalBeforeReturn Consider simply returning the value vs storing it in local variable …. Warning 제외요망 return 전에 따로 local 변수로 반환할 값을 선언할 때 주는 경고. 기능적으로는 별 의미 없는 코드이나, return 문장에는 @SupressWarning 의 Annotation을 추가할 수 없기 때문에, Annotation 적용 범위를 최소화하기 위해 그런 선언이 필요한 때도 있음. Debug Mode에서도 값의 추적에 약간의 편리성이 생길 수 있음. Java Language Spec 9.7, Effective Java 2ed - Item 24
Design Rules UncommentedEmptyConstructor Document empty constructor Warning 제외요망 빈 생성자에 comment가 없어도 코드의 이해에 무리가 없는 경우가 많음
Design Rules UncommentedEmptyMethod Document empty method Warning 제외요망 Listener류의 인터페이스의 구현에는 특정 메소드는 아무 일도 하지 않는 메소드로 남겨놓을 때도 있고, 종종 발생하는 상황임. 그리고 그 상황에 주석이 없다고 해도, 코드 이해에 무리가 없음
Design Rules ImmutableField Private field '...' could be made final; it is only initialized in the declaration or constructor.
EmptyInitializer
Warning 제외요망 멤버변수 중 선언되어서 한번만 값이 대입된 변수는 final로 할 수 있다고 알려주는 경고. 개발자가 Final로 의도하지 않지만, 현재 기능에서는 한번만 대입하고 있는 상황도 존재할 수 있다고 생각됨.
Jakarta Commons Logging Rules ProperLog Logger should be defined private static final and have the correct class
논의필요 private static final Log log = LogFactory.getLog(해당클래스) 로 로거를 선언할 것을 알려줌. 대체로 무난히 적용가능하나, 프로젝트의 로그 정책이 특별한 경우도 있으므로 논의해볼만 함
Java Bean Rules BeanMemberShouldSerialize Found non-transient, non-static member. Please mark as transient or provide accessors. Warning 제외요망 Java Bean의 명세를 검사하는 규칙. 일반적인 클래스는 transient하지 않으면서도 acessor가 없는 멥버 변수가 올 수 있는 경우가 많음. 스프링에서 선언하는 bean들은 setter만 가지는 경우가 많으므로 대부분 이 규칙에 어긋나게 됨. (스프링에서 bean은 java bean명세보다 보다 넓은 bean을 의미하는 것으로 생각하면 됨)
Java Loggins Rules Systemprintln System.out.print is used Error 논의필요 웹Application에서는 반드시 피해야할 코드라서 출시시에는 꼭 걸러내야하나, 분류가 Error가 되어 있는 것에 대한 논의는 필요함. 그리고 Console에서 도는 간단한 프로그램이나 테스트코드에서는 System.out이 들어가는 것이 결함이 아니므로 폴더 범위나 네이밍룰을 추가한 보다 정교한 Rule지정하는 것이 바람직함(예를 들어 Controller, Service, DAO안에는 System.out불가)
Junit Rules JunitAssertionsShouldIncludeMessage JUnit assertions should include a message Warning 제외요망 테스트 결과를 확인할 때, 메시지가 포함된 것이 바람직하나, 테스트 코드 작성을 장려하기 위해 테스트 코드에 대한 제약은 줄이는 것이 좋을 것으로 판단됨
Junit Rules JunitTestsShouldIncludeAssert JUnit tests should include assert() or fail() Warning 제외요망 assert나 fail이 있는 테스트코드가 의미가 있으나, 그렇지 않은 코드도 없는 것 보다는 나으므로, 테스트 코드 작성을 장려하기 위해 관대한 정책을 권장함
Migration Rules Junit4TestShouldUseTestAnnotation JUnit 4 tests that execute tests should use the @Test annotation Warning 제외요망 Junit3.8로 기준으로 작성된 코드에서 Junit4의 요건을 요구하면서 warning을 냄.
Naming Rules LongVariable Avoid excessively long variable names like … Warning 제외요망 표현력이 높은 변수이름을 짓는 것을 권장하기 위해서 길이제한을 두는 것은 바람직하지 않음
Naming Rules ShortVariable Avoid variables with short names like… Warning 논의필요 "is","os"등의 2글자 변수명일 때 나는 경고. 실제로 2글자만으로도 문맥상으로 충분한 표현력을 가지는 상황도 있고, 한 메소드가 크게 길어지지만 않는다면 local variable의 경우에는 다소 관대한 정책을 넣는 것도 무리는 없음
Optimization Rules AvoidInstantiatingObjectsInLoops Avoid instantiating new objects inside loops Warning 제외요망 Loop안에서 new keyword가 존재하면 나는 경고임. 피할 수 있는 경우라면 피해야 겠지만, GC시점이 약간이나마 늦어질 수 있고, collection.clear같은 청소 매서드 호출이 필요해진다거나, Thread safe해지지 않는 경우 등 손해가 있는 상황이 있으므로, 항상 지켜야할 지침이라고는 보기 어려움
Optimization Rules LocalVariableCouldBeFinal Local variable '...' could be declared final Warning 제외요망 local 변수 중 final이 될 수 있는 것을 알려주는 정보. Final이 되면 경고를 주는 이와 상반된 룰도 존재함
Optimization Rules MethodArgumentCouldBeFinal Parameter '...' is not assigned and could be declared final Warning 논의필요 방어적 프로그래밍을 위해서 파라미터는 final로 선언하는 것이 바람직하나, 모든 메서드를 그렇게 하면 메소드 시그니처가 전부 다 길어지기 단점이 있음. 기술인프라성 공통코드에만 적용하는 방안이 바람직하다고 생각함
Strict Exception Rules SignatureDeclareThrowsException A method/constructor shouldn't explicitly throw java.lang.Exception Warning 논의필요 메소드나 생성자가 throws Exception으로 최상위 Exception을 던질때 주는 경고. Checked Exception의 남발을 막고, 정교한 Exception선언을 돕는다는 장점도 있어서 되도록 권장하고 싶지만, 기존 코드의 Exception 선언이 throws Exception이 남용되어 있을 때 등 프로젝트 후반기에는 적용이 어려움
String and StringBuffer AvoidDpolicateLiterals The String literal " rows, page " appears 4 times in this file; the first occurrence is on line 70 Warning 논의필요 중복 되는 문자열 상수가 많은 경우에 나타남. 내부적으로는 java의 상수풀을 사용하게 되므로 성능에는 영향은 없음. 반복되는 문자열도 따로 상수선언을 하게 하는, 좋은 코딩습관에 도움이 되나 ,테스트 클래스 등의 안내 메시지 등의 그리 중요하지 않은 부분에서 지나친 상수선언을 하게 할 수 있음.

'I.lib() > I.lib(etc)' 카테고리의 다른 글

에디트 플러스 (Edit Plus) 칸단위 선택  (1) 2013.08.14
부산 여행 Tip  (0) 2013.08.09
겔럭시 s 부두 패치 경로  (0) 2013.04.19
[펌] TDD  (0) 2013.03.28
캐리커쳐 그리기 쉬운 사이트  (0) 2012.10.25
.
:
Posted by .07274.
2013. 4. 19. 10:53

겔럭시 s 부두 패치 경로 I.lib()/I.lib(etc)2013. 4. 19. 10:53

.. .. ..

http://cafe.naver.com/iroid/786690

'I.lib() > I.lib(etc)' 카테고리의 다른 글

부산 여행 Tip  (0) 2013.08.09
PMD Rule Set 정리 [펌]  (0) 2013.07.30
[펌] TDD  (0) 2013.03.28
캐리커쳐 그리기 쉬운 사이트  (0) 2012.10.25
7만번대 ps2 하드 플스 개조 (펌)  (0) 2011.08.04
.
:
Posted by .07274.
2013. 3. 28. 15:53

[펌] TDD I.lib()/I.lib(etc)2013. 3. 28. 15:53

.. .. ..

[펌] : http://soulpark.wordpress.com/2012/09/12/test-driven-development/

 

Test-Driven Development

린(Lean) 소프트웨어 개발론의 핵심 철학 중 하나는 “결함은 발견 즉시 해결”이다. 린 개발은 이것의 실천법으로 테스트 주도 개발(Test-Driven Development, TDD)을 제시한다. TDD 의 개념과 방법론 그리고 한계에 대해 알아보자.

TDD (Test-Driven Development) 란?

TDD는 반복 테스트을 이용한  소프트웨어 개발법이다. 작은 단위의 테스트 케이스를 작성하고 이를 통과하는 코드를 추가하는 단계를 반복하여 소프트웨어를 구현한다.

TDD의 목표는 작동하는 깔끔한 코드 “Clean code that works” 이다. 이를 위해 두 가지 원칙을 제시한다 .

  • 오직 자동화된 테스트가 실패할 경우에만 새로운 코드를 작성한다.
  • 중복을 제거한다.

린에서는 불필요한 기능 구현을 가장 큰 낭비로 여긴다. 이는 코드베이스의 복잡성을 높이고, 유지 보수를 어렵게 하여 높은 개발 비용을 초래한다. TDD도 테스트를 통과시키는 코드만을 작성함으로써 맥락을 같이한다.

요구사항 분석 -> 설계 -> 개발 -> 테스트 -> 배포 개발법엔 소프트웨어 개발을 느리게 하는 잠재적 위험이 존재한다.

  • 소비자의 요구사항이 처음부터 명확하지 않을 수 있다.
  • 따라서 처음부터 완벽한 설계는 어렵다.
  • 설계 -> 개발을 진행하면, 실제 코드와 설계간 갈등이 생길 수 있다.
  • 한 곳의 수정이 다른 곳에 미치는 영향을 확인 및 다른 기능의 정상 동작을 보장하기 어렵다.

TDD는 테스트 케이스를 생성한다. 테스트 케이스는 자동화된 테스트 도구로 이용되어, 코드 변경시 기존 기능이 제대로 동작하는지 쉽게 확인할 수 있고 정상 동작을 보장한다. 또한 TDD는 리펙토링을 개발 프로세스에 포함시켜 ‘변경’이라는 소프트웨어의 특성을 반영한다.

애자일 개발론의 Robert C. Martin은 다음의 TDD 원칙을 제시한다.

  • 실패하는 테스트를 작성하기 전에는 절대로 제품 코드를 작성하지 않는다.
  • 실패하는 테스트 코드를 한 번에 하나 이상 작성하지 않는다.
  • 현재 실패하고 있는 테스트를 통과하기에 충분한 정도를 넘어서는 제품 코드를 작성하지 않는다.

TDD 개발법

TDD는 아래 단계의 반복으로 진행된다.

  1. 빨강 : 실패하는 작은 테스트 케이스를 작성한다. 처음에는 컴파일조차 안될 수 있다.
  2. 초록 : 테스트를 통과하는 코드를 작성한다.
  3. 리펙터링 : 테스트를 통과하기 위해 만든 코드의 모든 중복을 제거하고, 불명확한 것을 명확히 한다.

이러한 단계로 인해 TDD는  ”업무 코드 작성 전에 테스트 코드를 먼저 만드는 것”으로 정의되기도 한다. 이해를 위해 간단한 sum 함수를 예제로 살펴보자.

  • 작성 메소드 이름 : sum
  • 기능 구현에 필요한 재료 (argument) : int a , int b
  • 반환 값의 타입 : int
  • 정상 동작 만족 조건 (작업 종료 조건) : a와 b 를 더한 값을 결과로 돌려줌

간단히 작성된 sum 함수의 테스트 조건이다. 꼭 위와 같은 형식이 아니라 하나의 문장이어도 된다. 단 테스트는 너무 크지 않은 규모여야 하며 테스트 통과 조건(작업 종료 조건)이 반드시 있어야 한다.

아래 예시 코드를 보자. (제품 코드 관리를 위해 테스트 클래스는 제품 클래스와 구분되어어 쌍을 이루는 것이 일반적이지만, 간단한 예시를 위해 하나의 클래스 안에 테스트 메소드와 제품 메소드를 같이 두었다.)

1
2
3
4
5
6
7
8
9
10
11
-(void)testMain{ // 테스트 메소드
 
    NSLog(@"True or False : %d",[self sumWithIntegers:10 :20] == 30);
    NSLog(@"True or False : %d",[self sumWithIntegers:1 :2] == 3);
    NSLog(@"True or False : %d",[self sumWithIntegers:-10 :20] == 10);
    NSLog(@"True or False : %d",[self sumWithIntegers:0 :0] == 0);
 
}
-(int)sumWithInteger:(int)a <img src="http://s0.wp.com/wp-includes/images/smilies/icon_sad.gif?m=1129645325g" alt=":(" class="wp-smiley"> int)b{ // 제품 메소드
    return 0;
}

먼저 테스트 메소드를 작성한다. 메소드 안에는 테스트 성공 여부를 확인할 수 있는 코드가 있다. 위 예제는 로그에 모두 True 가 나오면 테스트 케이스가 통과되었다고 가정한다.

제품 메소드보다 테스트 메소드를 먼저 작성하므로 sumWithIntegers: 메소드를 찾을 수 없다는 컴파일 에러가 발생한다. 의아해 할 필요없다. 의도한 바다. 테스트 코드를 작성하면서 자연스럽게 제품 코드의 클래스 이름 및 메소드 이름 등의 설계 요소를 고민하게 된다.

다음 단계로 테스트 케이스의 결과를 ‘통과’로 만든다. 컴파일 오류 해결을 위해 sumWithIntegers: 메소드를 정의한다. 그리고 메소드 안에 테스트를 만족시키는 코드를 작성한다. (예시에서는 단순히 0을 리턴하였다. 제품 코드를 먼저 작성하지 않음을 보여주기 위함이다.)

테스트가 통과되면 테스트 수행에 사용된 테스트 클래스와 제품 클래스 모두 리펙토링한다. 필드 이름, 중복 제거, 가독성 향상 등 간결한 코드를 유지하여 변경에 유연한 코드를 만들도록 노력한다. 리펙터링은 이전의 테스트 케이스를 모두 통과시켜야만 한다. 개발 단계에서  테스트 케이스가 누적되어 유지되므로 이전 기능들에 대한 정상 동작 여부가 보장된다. (위 예시는 지극히 간단하여 리펙토링 단계 없음)

개인적으로 다음의 역량이 TDD 개발에 있어 개발자에게 중요할 것 같다.

  • 테스트 케이스 작성 능력 : 테스트 케이스 자체가 의미있지 않으면 개발된 코드를 신뢰할 수 없다.
  • API 숙련도 : 테스트 케이스를 먼저 작성하면 컴파일 조차 되지 않아 개발 도구의 자동 완성 기능의 도움을 받지 못할 수 있다.
  • 설계 및 리펙토링 능력 : 매 단계마다 상황에 맞는 설계적 결정을 해야 한다. 전체 SW 구조에 대한 직관을 가질 필요가 있다.

테스트 케이스가 의미있으려면 테스트 케이스는 정상적으로 끝까지 수행되어야 한다. 테스트의 결과 중 개발자가 의도 하지 않은 문제 – 예상치 못한 Exception 등 – 는 실패가 아닌 오류로 기록된다. 테스트 케이스가 정상적으로 끝까지 진행되어 오류가 아닌 실패로 기록되도록 하자.

테스트 클래스를 생성/사용할 때는 제품코드와 ‘소스 코드는 다르게, 패키지는 동일, 컴파일된 클래스는 다른 곳으로’ 설정하는 방법이 가장 많이 쓰인다. 폴더만으로 제품 코드와 분리하면 테스트만을 위한 라이브러리를 구별하기가 어려워진다.

일반적으로 TDD에는 Unit Test Framework이 많이 사용된다. iOS 개발 도구 Xcode에는 OCUnit Test Framework이 내장되어 있다.

TDD 장점

  • 개발자의 방향을 잃지 않게 유지: 현재 자신의 개발 내용 및 진척 상황을 항상 살펴볼 수 있다.
  • 품질 높은 소프트웨어 모듈 보유 : 간결한 코드 유지 가능
  • 자동화된 단위 테스트 케이스 소유: 개발자가 필요한 시점에 언제든 수행할 수 있으며 시스템의 이상 유무를 바로 확인할 수 있다.
  • 사용설명서 & 의사 소통의 수단:  작성된 테스트 케이스는 제품 코드 사용 설명서이자 동시에 다른 개발자와 소통하는 커뮤니케이션 통로가 된다. (제품 코드 API 사용 예시가 된다.)
  • 설계 개선 : 테스트 케이스 작성 시 개발에 포함된 다양한 설계요소들에 대해 고민하게 된다. 흔히 테스트하기 어렵다고 생각되는 코드들은 객체 설계 원리 중 기본에 해당하는 원칙들이 잘못 적용됐거나 충분히 고려되지 않았을 가능성이 높다. TDD 진행하면서 테스트가 가능하도록 설계 구조를 고민하다 보면 자연스럽게 디자인을 개선하게 된다.
  • 보다 자주 성공한다 : TDD 는 주기를 짧게 설정하도록 권한다. 개발자는 성취감을 자주 느낄 수 있다.

TDD 의 한계

TDD 선구자인 Kent Beck 은 다음 두 가지를  TDD가 현재 접근하기 어려운 분야라고 말한다.

  • 동시성(Concurrency)
  • 보안 등의 비기능적 요소

이 외에 국내 TDD 도서 저자인 채수원씨는 본인의 도서에서 아래와 같이 추가적인 어려움들을 덧붙였다. 불가능하진 않지만 쉽지 않다는 의미로 받아들이면 될 것 같다.

  • 접근 제한자 메소드 : 현재는 public 메소드만 테스트해도 무방하다는 경향이 대세로 보이지만, 필요에 따라 public 으로 테스트 후 접근 제한자를 수정하는 방법도 있다.
  • GUI : 뷰 레이어와 로직 레이어를 확실히 분리시켜 설계할 필요가 있다.
  • 의존성 모듈 테스트 (target = A but A -> B) : 타겟 A 테스트를 위해 B 도 필요하다. 그러나  B가 아직 준비가 되어 있지 않다면 테스트가 이루어질 수 없다. 보통 이런 경우 B의 Mock객체를 생성하여 B는 문제없음을 가정하고 테스트 한다.

* Updated 9/14 , 접근제한자 메소드 한계 : TDD 단계를 준수하면  Private 메소드는 빨강 – 초록 단계를 지나 리펙토링 단계에서 생성된다. Private 메소드는 새로운 테스트 케이스가 필요한 것이 아니라 이미 통과한 테스트의 리펙토링 결과다. 별도로 접근제한자를 변경해서 테스트할 필요가 없다. 그렇게 되도록 TDD 개발 단계를 준수하자.

* Reference

 

'I.lib() > I.lib(etc)' 카테고리의 다른 글

PMD Rule Set 정리 [펌]  (0) 2013.07.30
겔럭시 s 부두 패치 경로  (0) 2013.04.19
캐리커쳐 그리기 쉬운 사이트  (0) 2012.10.25
7만번대 ps2 하드 플스 개조 (펌)  (0) 2011.08.04
하드 플스 관련 주소  (0) 2011.04.26
.
:
Posted by .07274.
2012. 10. 25. 11:37

캐리커쳐 그리기 쉬운 사이트 I.lib()/I.lib(etc)2012. 10. 25. 11:37

.. .. ..
http://www.befunky.com/

 

'I.lib() > I.lib(etc)' 카테고리의 다른 글

겔럭시 s 부두 패치 경로  (0) 2013.04.19
[펌] TDD  (0) 2013.03.28
7만번대 ps2 하드 플스 개조 (펌)  (0) 2011.08.04
하드 플스 관련 주소  (0) 2011.04.26
주루마블  (0) 2010.12.27
.
:
Posted by .07274.
.. .. ..

'I.lib() > I.lib(etc)' 카테고리의 다른 글

[펌] TDD  (0) 2013.03.28
캐리커쳐 그리기 쉬운 사이트  (0) 2012.10.25
하드 플스 관련 주소  (0) 2011.04.26
주루마블  (0) 2010.12.27
ojdbc14 // 부적합한 열 유형 에 대한 대처법. // oracle  (3) 2010.09.06
.
:
Posted by .07274.