JAVA_HOME 환경변수는 자바 개발의 시작입니다. 윈도우7에서 환경변수를 설정하는 방법을 알아봅니다.


탐색기에서 컴퓨터를 선택하고 컨텍스트 메뉴의 속성을 엽니다. 좌측에서 고급 시스템 설정을 클릭합니다.



고급 탭에서 하단의 환경 변수(N)... 버튼을 클릭합니다.



하단의 시스템 변수(S) 항목에서 JAVA_HOME을 선택하고 편집 버튼을 클릭합니다. 만약 처음이라면 새로 만들기(W)... 버튼을 클릭합니다.


변수 이름에 JAVA_HOME 을 입력하고, 변수 값에 설치된 경로를 붙여넣습니다. 

그리고 확인 버튼으로 열린 창들을 닫습니다.


cmd 창을 닫았다가 다시 엽니다. echo %JAVA_HOME% 라고 입력하면 설정된 환경변수 값을 확인할 수 있습니다.


한 가지 환경변수가 더 설정이 되어야 합니다. 바로 %Path% 입니다.

%JAVA_HOME%\bin; 

위 경로를 시스템 환경 변수 Path에 추가합니다. 

참고: http://okjsp.tistory.com/1165643255


from: http://www.zentus.com/sqlitejdbc/ 
구글링해서 제일 먼저 나온 사이트입니다. 검색어는 sqlite jdbc 였죠. freshmeat project로 버전업 발표가 된다고 합니다. 
sqlite3를 보고 처음 든 생각은 음, 이거 자바에서 어떻게 연결하지 였습니다. 리스너 또는 데몬이 떠 있지 않기 때문이죠. sqlitejdbc를 써보고 난 느낌은 약간 허탈했습니다. 원래 데몬이 뜨지 않더군요. 파일DB 입출력을 ANSI SQL로 만들어 놓은 느낌이었습니다. 따로 프로세스가 도는 것이라기보다는 애플리케이션에 애드온으로 삽입된 느낌이라고 할까요.

sqlitejdbc에는 현재 sqlite3가 포함되어 있습니다. 따로 sqlite를 받지 않아도 됩니다. 이클립스에서 테스트한 프로젝트 통째로 압축해서 올립니다. 라이센스는 BSD군요.


jdbc에 익숙한 분들은 아시겠지만 코드는 간결합니다.
사용법(usage) 부분에 사용시 주의사항이 나와 있습니다. 경량DB의 제한사항이 있으니 꼭 숙지하고 작업하셔야 할 것 같습니다. 항목은 다음과 같습니다.

간단한 DB가 필요할 때 유용할 것 같습니다. 대용량이나 빈번한 사용은 아직 무리겠지요.

백기선님이 잘 번역하신 글입니다.
http://www.ibm.com/developerworks/kr/library/j-ap07088/index.html?ca=drs-kr 
findbugs를 통해서 코드의 취약성을 발견할 수 있었습니다.

CheckStyle, PMD, JDepend 등의 도구는 코드의 유지보수성과 가독성, 확장성을 떨어뜨리는 구문을 찾아줍니다.
이러한 도구들의 사용법과 리팩토링에 대한 글이 올라왔습니다. 아울러 글에서는 Switch구문을 polymorphism으로 리팩토링하기, 중복코드 줄이기, 긴 메소드(큰 클래스) 경량화하기, 너무 많은 import 줄이기 등에 대한 예들이 나옵니다.

참고하시면 좋은 애플리케이션 만드는데 큰 힘이 될 것입니다.

고전적인 자바 클래스의 테스트는 main() 메소드에 값을 찍어보는 코드를 넣어서 콘솔에서 확인합니다. 이클립스에 익숙해진 덕에 JUnit에서 System.out.println() 집어 넣는 것은 초딩같은 습관이라고 생각을 "저만"했었습니다. 하지만, 찍어본다는 것 그리고 그것을 눈으로 확인하는 것은 굉장한 심리적 안정감을 주기는 합니다. 아직 assertEquals() 는 보이지 않는 신뢰가 필요하기 때문이죠.

httpunit의 테스트코드를 보니 재밌는 부분이 있었습니다. 상당히 많은 수의 테스트케이스에 main() 메소드가 있었고, 그 메인메소드는 JUnit을 기반으로 해당 테스트코드를 수행하도록 만들어주는 것이었습니다.


suite() 메소드를 inline 리팩토링하면 junit.textui.TestRunner.run( new TestSuite( EncodingTest.class ));  를 통해서 실행을 합니다. Java Application 으로 실행한 결과는 다음과 같습니다.

..............
Time: 3.813

OK (14 tests)

물론 이 클래스는 JUnit을 통해서도 실행됩니다.

다른 사람의 코드를 읽는 것, 프로그래머 소통의 시작이 아닐까 생각해봅니다.

참고로 HttpUnitTest 클래스의 상속구조입니다. ctrl+T 로 이클립스에서 볼 수 있습니다.


 

최근 TSS에 재밌는 기사가 하나 떴습니다. 테스트케이스가 공식적으로 개발과정에 포함되는지 아니면 비공식적으로 만들어지는지에 관한 조사였습니다. 2006년에 이어서 2년 후인 2008년 설문을 진행했습니다. 데이터는 다음과 같습니다.

Answers 2008 (2006)
Unit testing is not performed: 17% (13%)
Unit testing is informal: 40% (46%)
Unit tests cases are documented: 9% (11%)
Unit tests cases and their executions are documented: 14% (16%)
We use a Test Driven Development approach: 20% (14%)

Participants: 384 (2006: 460)
Ending date: October 2008 (February 2006)
Source: Methods & Tools (http://www.methodsandtools.com/)

TDD 접근법을 사용하는 것은 20%로 증가한 것에 비해 단위테스트에 대한 노력은 오히려 감소했습니다. 그리고 의외인 것은 외국에서도 아직 단위테스트가 보편적이지 않다는 것이었습니다.

오픈소스 프로젝트 하나를 앞서 살펴봤습니다. 여기에는 test라는 테스트케이스를 모아놓은 폴더가 있었습니다. 소스의 양은 얼마나 될까요. httpunit 이라는 단위테스트용 프로젝트이기 때문에 좀 더 많이 있을 거라 예상했습니다.
예상대로 제가 회사에서 만든 테스트코드들과는 비교할 수 없이 많더군요.

요기까지가 패키지 하나에 들어있는 소스 코드들입니다. 이 코드들을 테스트하는 테스트케이스는 다음과 같습니다.
그리 많은 것은 아니지만 대략 1/5 정도 테스트케이스의 클래스들이 있지않나 생각됩니다. 각 테스트케이스 내의 테스트 메소드들이 애플리케이션에 대한 코드 커버리지를 책임지겠지요.

테스트케이스를 모아놓은 것이 테스트스위트입니다. *Suite.java 로 찾아보면 다음과 같은 스위트들이 보입니다.

빌드 스크립트에서도 테스트 관련 배치작업을 찾을 수 있습니다.



test 타겟을 실행해보니 다음과 같은 결과가 나오는군요.
test:
     [java] .........................................
     [java] .........................................
     [java] .........................................
     [java] .........................................
     [java] .........................................
     [java] .........................................
     [java] .........................................
     [java] .........................................
     [java] .........................................
     [java] .....................................F....
     [java] .........................................
     [java] .........................................
     [java] .........................................
     [java] .........................................
     [java] .........................................
     [java] .........................................
     [java] .........................................
     [java] .........................................
     [java] .....................................
     [java] Time: 22.656
     [java] There was 1 failure:
     [java] 1) testCookieAge(com.meterware.httpunit.cookies.CookieTest)junit.framework.AssertionFailedError: cookie2 expiration expected:<1223798608260> but was:<1112124642000>
     [java]  at com.meterware.httpunit.cookies.CookieTest.testCookieAge(CookieTest.java:202)
     ...
     [java]  at com.meterware.httpunit.HttpUnitSuite.main(HttpUnitSuite.java:49)
     [java] FAILURES!!!
     [java] Tests run: 775,  Failures: 1,  Errors: 0
BUILD SUCCESSFUL
Total time: 36 seconds

디버깅을 할 것은 아니지만, 이렇게 테스트케이스를 775가지 이상 갖고 있는 애플리케이션을 관리하는 것은 좀 더 수월하지 않을까 생각됩니다. 작업환경의 차이에서 발생하는 버그도 찾을 수 있고, 코드 변경으로 인한 틀어짐도 놓치지 않기 때문입니다.

읽어주셔서 감사합니다. 알찬 11월 되시길...
앞서 오픈소스를 통해서 소스 저장소에 등록되는 디렉토리 구조를 살펴보았습니다. 그리고 프로젝트 소스를 일괄처리하는 build.xml 도 살짝 들여다 보았습니다. 이클립스 툴을 쓰면 다 되는 작업을 왜 Ant 빌드스크립트를 만들어야하는지 질문을 종종 들어봤습니다. 지속적인 통합 빌드 같이 주기적으로 반복되는 작업이나 단계가 복잡한 작업들은 빌드스크립트가 효과적입니다. 클릭클릭하는 일도 지겨울 때가 있거든요. 이클립스 작업의 자동화가 빌드 스크립트라고 생각하시면 될 것입니다.

지난 번 소스 가져오기(import) 이후로 소스의 빌드 경로를 잡아보려고 합니다. 로컬pc에서 컴파일되나 안되나 확인하는 것이죠. 소스가 패키지에 맞게 제자리에 있어야 할 것이고, 참조하는 jar파일의 경로도 함께 지정해줘야 합니다.

일단 이클립스 자바 프로젝트에서 소스 폴더를 추가합니다. 자바소스가 있는 폴더를 소스폴더라고 합니다. *.java 파일과 *.properties 파일들이 위치합니다. httpunit-1.7 아래 src 폴더가 바로 소스폴더입니다. 그리고 httpunit-1.7 아래 test 라는 곳도 소스 폴더로 추가합니다. src 아래 있는 클래스들을 테스트하는 테스트케이스들의 소스 폴더입니다.

자동 빌드가 일어나면서 에러가 무진장 일어납니다. jar 파일 연결이 안되서 그렇습니다.

왼쪽 패키지 익스플로러에서 프로젝트를 선택하고 Properties 창을 엽니다. 컨텍스트 메뉴에서 제일 아래 Properties 메뉴를 선택하면 됩니다. 단축키는 alt+Enter
Java Build Path 항목을 선택하고 Libraries 탭을 클릭합니다.

우측의 Add JARs... 버튼을 클릭해서 httpunit-1.7/jars 폴더의 *.jar 파일들을 선택합니다.

오호, 에러가 줄기는 했는데, 하나 남았네요. fnfe를 클릭해서 해당 소스를 열어보겠습니다. 흠, 겁을 상실했군요. 에~ 뭐 꼭 고친다는 뜻은 아닙니다. ^^;

소스를 살짝 보니 캐릭터셋 문제로 Roger Lindsj 이름 옆에 이상한 문자가 생긴 것 같네요. 그것 때문에 아랫줄 if라인이 주석 줄로 따라 올라온 듯 합니다.

if 앞에서 엔터로 줄바꿔주니 고쳐졌습니다. ^^; 잠시 우쭐~

Problems 탭에 에러는 싹 사라졌군요. Warnings는 살짝 봐주기로 하죠. ^^;

소스 폴더가 추가된 모습입니다.

작업공간은 에러 없는 코드로 관리되는 것이 개발자 심리에 좋다고 생각을 합니다. ^^;


update site url 입니다. http://findbugs.cs.umd.edu/eclipse/
설치가 완료되면 다음과 같은 메뉴가 보입니다.

테스트용으로 에러를 발생시키는 소스를 만들어서 테스트 해봅니다.

package net.okjsp;

public class HelloWorld {

 /**
  * @param args
  */
 public static void main(String[] args) {
  String arg = null;
  System.out.println("Hello World! "+arg.equals("0"));

 }

}


문제가 되는 라인 앞에 버그가 표시됩니다. 더블클릭하면 하단에 findbugs 뷰가 생깁니다.


해당 버그의 내용과 수정 방법에 대해서 표시됩니다.

뷰 메뉴 중 findbugs 퍼스펙티브로 전환하는 아이콘도 있습니다.

클릭하면 다음과 같은 정보를 확인할 수 있습니다.

이제 쎄스코를 부르지 않아도 될 것 같습니다.

 

+ Recent posts